Re: liquidshell in kdereview
I've now moved this to extragear/base as there did not seem to be any more political complaints and technical ones seemed fairly fixable. Jonathan On Mon, 15 Apr 2019 at 10:16, Martin Koller wrote: > On Sonntag, 14. April 2019 23:34:43 CEST Luca Beltrame wrote: > > Il giorno Sun, 14 Apr 2019 16:43:54 +0200 > > Martin Koller ha scritto: > > > > > The cmake file is the ultimate source for specifying what the > > > application depends on. Adding this somewhere else will easily get > > > > READMEs can be useful for packagers instead of manually watching the > > output of CMake or reading CMakelists.txt (fine for simpler projects, > > but not for large ones). > > since in this case we are talking about required software, > the packager will not get the app compiled. > I assume this will hit his attention. > I would understand that optional dependencies are different since the app > would build but not with all options. > > -- > Best regards/Schöne Grüße > > Martin > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > > > >
Re: liquidshell in kdereview
On Sonntag, 14. April 2019 23:34:43 CEST Luca Beltrame wrote: > Il giorno Sun, 14 Apr 2019 16:43:54 +0200 > Martin Koller ha scritto: > > > The cmake file is the ultimate source for specifying what the > > application depends on. Adding this somewhere else will easily get > > READMEs can be useful for packagers instead of manually watching the > output of CMake or reading CMakelists.txt (fine for simpler projects, > but not for large ones). since in this case we are talking about required software, the packager will not get the app compiled. I assume this will hit his attention. I would understand that optional dependencies are different since the app would build but not with all options. -- Best regards/Schöne Grüße Martin () ascii ribbon campaign - against html e-mail /\- against proprietary attachments
Re: liquidshell in kdereview
Il giorno Sun, 14 Apr 2019 16:43:54 +0200 Martin Koller ha scritto: > The cmake file is the ultimate source for specifying what the > application depends on. Adding this somewhere else will easily get READMEs can be useful for packagers instead of manually watching the output of CMake or reading CMakelists.txt (fine for simpler projects, but not for large ones). -- Luca Beltrame GPG key ID: A29D259B pgpJP4dfjoxjC.pgp Description: Firma digitale OpenPGP
Re: liquidshell in kdereview
On Sonntag, 14. April 2019 12:44:20 CEST Adriaan de Groot wrote: > On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote: > > > # License issues > > > > > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > > > want to add SPDX identifiers, but that would be the icing on the cake. > > > > Where, which and how would I need to add SPDX identifiers ? > > You don't *need* to. Like I said, icing on the cake, which is like .. vanilla > sauce on the apfelstruedel. Makes it complete and wonderful, but it's > acceptable without it. > > SPDX identifiers are machine-readable, standardised, tags in source files > that > help tooling that works with licensing (meta) data. See spdx.org; something > like (off the top of my head, not necessarily the right identifier or format, > etc.) > > // SPDX-Identifier: GPLv2+ > > at the top of C++ source files does the trick. ok, done. > > Where is this documented in KDE guidelines ? > > Here > > https://community.kde.org/Policies/Licensing_Policy > > I don't find anything. > > It's not. should it ? > > > # Compatibility issues > > > > > > Fails to document that NetworkManager and BlueZ are required. > > > > Not sure I understand. > > Would have been nice to have that in the README, is what I mean. I'm not a fan of doing duplicate things. The cmake file is the ultimate source for specifying what the application depends on. Adding this somewhere else will easily get out of sync. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote: > > # License issues > > > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > > want to add SPDX identifiers, but that would be the icing on the cake. > > Where, which and how would I need to add SPDX identifiers ? You don't *need* to. Like I said, icing on the cake, which is like .. vanilla sauce on the apfelstruedel. Makes it complete and wonderful, but it's acceptable without it. SPDX identifiers are machine-readable, standardised, tags in source files that help tooling that works with licensing (meta) data. See spdx.org; something like (off the top of my head, not necessarily the right identifier or format, etc.) // SPDX-Identifier: GPLv2+ at the top of C++ source files does the trick. > Where is this documented in KDE guidelines ? > Here > https://community.kde.org/Policies/Licensing_Policy > I don't find anything. It's not. > > # Source issues > > > > Doesn't report nicely at end of CMake (use FeatureSummary). > > included now Thanks. > > # Compatibility issues > > > > Fails to document that NetworkManager and BlueZ are required. > > Not sure I understand. Would have been nice to have that in the README, is what I mean. > > Uses bash for things that are POSIX shell scripts. > > What do you mean ? You have a shell script (start_liquidshell). It uses no bash features at all. A POSIX system (ok, liquidshell is for Linux only, so this can be argued) has a /bin/sh for shell scripts. > I did this since I remember having read that /bin/sh is not the correct way. Fine by me. [ade] signature.asc Description: This is a digitally signed message part.
Re: liquidshell in kdereview
On Freitag, 12. April 2019 13:07:41 CEST Marco Martin wrote: > On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić wrote: > > Anyhow, while I do find it strange to market a non-feature in the features > > list, I don't have anything against it. > > I have a bit of a problem about putting doesn't use activities as a > feature, because it's a bit confrontational towards other KDE products > (and as you point out, often not 100% true as kactivitymanagerd will > be very probably started anyways) I have removed the mentioning of activities now > That said, i don't have problems of having a competing shell as a KDE > project, choice is usually good. Thanks for your open mind! -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Freitag, 12. April 2019 12:48:17 CEST Adriaan de Groot wrote: > On Sunday, March 10, 2019 1:25:14 PM CEST Martin Koller wrote: > > since some time has already passed and there was no conclusion, I'll try > > once again to announce liquidshell. > > # Documentation issues > > The features list, both in German and English, lists a bunch of features that > distinguish it from, say, twm, not from Plasma. I don't understand your point. What do you want me to change? > The feature list in English doesn't match the one in German. The English one > includes dubious claims such as "instant startup" and "low memory footprint", > which I'd still want to see measured and/or demonstrated. you can see them when you start liquidshell. What do you want me to change ? > Typo's in (English) README. > > # License issues > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > want > to add SPDX identifiers, but that would be the icing on the cake. Where, which and how would I need to add SPDX identifiers ? Where is this documented in KDE guidelines ? Here https://community.kde.org/Policies/Licensing_Policy I don't find anything. > # Source issues > > Doesn't report nicely at end of CMake (use FeatureSummary). included now > # Compatibility issues > > Fails to document that NetworkManager and BlueZ are required. Not sure I understand. The cmake file includes find_package(KF5 REQUIRED COMPONENTS for NetworkManagerQt and BluezQt > Uses bash for things that are POSIX shell scripts. What do you mean ? There is exactly one shellscript which is not build related: start_liquidshell it contains #!/bin/bash if you're referring to this. I did this since I remember having read that /bin/sh is not the correct way. > Those (two items) above are symptoms of "liquidshell is a shell for Martin > Koller and people with exactly his computer setup and workflow". "my workflow" - of course. "exactly his computer" - not so. E.g. it seems Arch Linux provides liquidshell: https://aur.archlinux.org/packages/liquidshell-git/ Also KaOS have included liquidshell https://linuxscoop.com/video/whats-new-kaos-2018-01 I'm using openSuse. > Since the KDE community has traditionally produced general, flexible > software, it's weird to > have a restricted, limited, non-flexible product as well. If you find liquidshell too limited and unflexible for you, don't use it. liquidshell's intent is exactly being this: simple and not over complex (aka general, flexible) -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić wrote: > Anyhow, while I do find it strange to market a non-feature in the features > list, I don't have anything against it. I have a bit of a problem about putting doesn't use activities as a feature, because it's a bit confrontational towards other KDE products (and as you point out, often not 100% true as kactivitymanagerd will be very probably started anyways) That said, i don't have problems of having a competing shell as a KDE project, choice is usually good. Marco Martin
Re: liquidshell in kdereview
On Sunday, March 10, 2019 1:25:14 PM CEST Martin Koller wrote: > since some time has already passed and there was no conclusion, I'll try > once again to announce liquidshell. # Documentation issues The features list, both in German and English, lists a bunch of features that distinguish it from, say, twm, not from Plasma. The feature list in English doesn't match the one in German. The English one includes dubious claims such as "instant startup" and "low memory footprint", which I'd still want to see measured and/or demonstrated. Typo's in (English) README. # License issues None, actually. Well done. Consistent use of GPLv3+ everywhere. You might want to add SPDX identifiers, but that would be the icing on the cake. # Source issues Doesn't report nicely at end of CMake (use FeatureSummary). Ancient CMake and Qt versions listed as "minimum" (that's ok, I guess). Unusual source layout and file suffixes (again, I guess it's ok, just weird and being difficult). Poor C++11 hygiene (include guards, conversions, nullptr). # Compatibility issues Fails to document that NetworkManager and BlueZ are required. Uses bash for things that are POSIX shell scripts. Those (two items) above are symptoms of "liquidshell is a shell for Martin Koller and people with exactly his computer setup and workflow". Since the KDE community has traditionally produced general, flexible software, it's weird to have a restricted, limited, non-flexible product as well. [ade] signature.asc Description: This is a digitally signed message part.
Re: liquidshell in kdereview
> Same as if you use Gnome Shell instead of liquidshell, no? > > If the application locks itself in a bad state depending the Desktop in use, > that's a bug of the application not of the desktop. Yes and no. KWin can force applications to be on specific activities. The fact that liquidshell makes no use of activities does not mean that activities are disabled. Namely, KWin uses activities, KWin will start the activity manager daemon and KWin will handle windows as it does on Plasma. Dolphin, Gwenview, etc. will still use activities as they do now. Nothing will change in that regard. So, liquidshell doesn't use activities means: - it does not react to activity changes - it does not offer a way to switch activities, even if they still exist Anyhow, while I do find it strange to market a non-feature in the features list, I don't have anything against it. If people want to use liquidshell instead of plasma or lxqt, why would we stop them? I don't think we've had 'political' discussions in the review phase before, and I don't think we should now. Cheers, Ivan -- dr Ivan Čukić KDE, ivan.cu...@kde.org, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Re: liquidshell in kdereview
El dimarts, 12 de març de 2019, a les 9:46:19 CET, Tomaz Canabrava va escriure: > On Tue, Mar 12, 2019 at 9:34 AM Martin Koller wrote: > > > > On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote: > > > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller wrote: > > > > > > > > Hi, > > > > > > > > since some time has already passed and there was no conclusion, I'll > > > > try once again > > > > to announce liquidshell. > > > > > > > > I have made adjustments to the README which now says: > > > > > > > > liquidshell is a basic Desktop Shell implemented using QtWidgets. > > > > > > > > Main Features: > > > > - Wallpaper per virtual desktop > > > > - No animations, low memory and CPU footprint > > > > - Instant startup > > > > - No use of activities > > > > > > How apps that deal with activities will work on? they will just > > > silently ignore activities? > > > > Since I do not use activities, I have no idea. > > But since liquidshell does not even offer anything related to activities, > > why would an application face an issue with that in the first place ? > > Because I could use plasma and activities and then install liquidshell > to test, to discover that I'm unable to launch the application in the > state that I left. > I, as user, being unable to reach an already configured application > state, would consider that Liquidshell has a bug related to the > loading of applications. Same as if you use Gnome Shell instead of liquidshell, no? If the application locks itself in a bad state depending the Desktop in use, that's a bug of the application not of the desktop. Cheers, Albert > > > -- > > Best regards/Schöne Grüße > > > > Martin > > A: Because it breaks the logical sequence of discussion > > Q: Why is top posting bad? > > > > () ascii ribbon campaign - against html e-mail > > /\- against proprietary attachments > > > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > > > > >
Re: liquidshell in kdereview
On Tue, Mar 12, 2019 at 9:34 AM Martin Koller wrote: > > On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote: > > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller wrote: > > > > > > Hi, > > > > > > since some time has already passed and there was no conclusion, I'll try > > > once again > > > to announce liquidshell. > > > > > > I have made adjustments to the README which now says: > > > > > > liquidshell is a basic Desktop Shell implemented using QtWidgets. > > > > > > Main Features: > > > - Wallpaper per virtual desktop > > > - No animations, low memory and CPU footprint > > > - Instant startup > > > - No use of activities > > > > How apps that deal with activities will work on? they will just > > silently ignore activities? > > Since I do not use activities, I have no idea. > But since liquidshell does not even offer anything related to activities, > why would an application face an issue with that in the first place ? Because I could use plasma and activities and then install liquidshell to test, to discover that I'm unable to launch the application in the state that I left. I, as user, being unable to reach an already configured application state, would consider that Liquidshell has a bug related to the loading of applications. > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > >
Re: liquidshell in kdereview
On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote: > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller wrote: > > > > Hi, > > > > since some time has already passed and there was no conclusion, I'll try > > once again > > to announce liquidshell. > > > > I have made adjustments to the README which now says: > > > > liquidshell is a basic Desktop Shell implemented using QtWidgets. > > > > Main Features: > > - Wallpaper per virtual desktop > > - No animations, low memory and CPU footprint > > - Instant startup > > - No use of activities > > How apps that deal with activities will work on? they will just > silently ignore activities? Since I do not use activities, I have no idea. But since liquidshell does not even offer anything related to activities, why would an application face an issue with that in the first place ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
El diumenge, 10 de març de 2019, a les 13:25:14 CET, Martin Koller va escriure: > Hi, > > since some time has already passed and there was no conclusion, I'll try once > again > to announce liquidshell. > > I have made adjustments to the README which now says: > > liquidshell is a basic Desktop Shell implemented using QtWidgets. > > Main Features: > - Wallpaper per virtual desktop > - No animations, low memory and CPU footprint > - Instant startup > - No use of activities I feel like this is still Plasma feature bad mouthing. To you it is somehow a feature because you think activities are bad, so that's why you list it as a feature, but honestly it is also a feature of GNOME Shell and almost every other single desktop environment out there, and they don't announce it, why should you? Cheers, Albert
Re: liquidshell in kdereview
On Sun, Mar 10, 2019 at 1:25 PM Martin Koller wrote: > > Hi, > > since some time has already passed and there was no conclusion, I'll try once > again > to announce liquidshell. > > I have made adjustments to the README which now says: > > liquidshell is a basic Desktop Shell implemented using QtWidgets. > > Main Features: > - Wallpaper per virtual desktop > - No animations, low memory and CPU footprint > - Instant startup > - No use of activities How apps that deal with activities will work on? they will just silently ignore activities? > - QtWidgets based, therefore follows widget style from systemsettings > - Icons are used from your globally defined icon theme from systemsettings > - Colors are used from your globally defined color theme from systemsettings > - Can additionally be styled with css by passing the commandline option > -stylesheet filename.css > (see included example stylesheet.css) > - uses existing KDE Frameworks dialogs for most configurations, e.g. > StartMenu, Virtual Desktops, Bluetooth, Network > - Just one bottom DesktopPanel, containing: > StartMenu (allowing drag of entries into konqueror/dolphin to configure > QuickLaunch or AppMenu entries) > QuickLaunch (showing icons for .desktop files from a configurable folder) > AppMenu (showing .desktop files in a menu from a configurable folder, > defaults to users desktop folder) > Pager (for switching virtual desktops) > WindowList (Popup showing all open windows on all desktops) > TaskBar (showing windows on the current desktop, allowing drag of an entry > onto the Pager to move to a different desktop) > LockLogout > SysLoad widget including CPU, Memory, Swap and Network bars, live updated > tooltip > SysTray with integrated Network-, Notifications-, Device Notifier-, > Bluetooth-, Battery- display. > It also features PackageKit software updates integration. > The DeviceList also shows devices connected and paired with KDEConnect. > Display of StatusNotifier items from other applications (no legacy > embedded icons yet). > Notifications kept in a history list for some minutes, including > timestamp and text selectable per mouse > (very handy for copy/paste of TAC numbers from online banking received > via SMS and transferred to KDE >via kdeconnect) > Clock widget (with calendar popup, tooltip for selected cities) > > I think the final place should be extragear. > > openSuse's OBS has already packages for some distributions > > Screenshots: > http://members.aon.at/m.koller/liquidshell_20190310_light.png > http://members.aon.at/m.koller/liquidshell_20190310_dark.png > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > >
Re: liquidshell in kdereview
El diumenge, 3 de desembre de 2017, a les 13:51:49 CET, Martin Flöser va escriure: > Am 2017-12-03 12:28, schrieb Albert Astals Cid: > > El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser > > va > > > > escriure: > >> Am 2017-12-02 10:17, schrieb Albert Astals Cid: > >> > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va > >> > > >> > escriure: > >> >> Am 2017-11-29 21:23, schrieb Martin Koller: > >> >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > >> >> >> Hi all, > >> >> >> > >> >> >> I'd like to announce an application I've implemented over the last > >> >> >> few > >> >> >> weeks - liquidshell > >> >> > > >> >> > since more than 3 weeks have passed, I hopefully have addressed all > >> >> > issues and I got no further comments, > >> >> > are there any blocking points you see or can I proceed requesting > >> >> > the > >> >> > move to extragear ? > >> >> > >> >> Yes I still see several blocking items. E.g. > >> >> "liquidshell is an alternative to plasmashell" > >> >> > >> >> I think that should be removed. I do not want any competing or > >> >> alternative to plasmashell provided by KDE. This would be very bad for > >> >> our community. Please formulate the readme without mentioning Plasma. > >> >> I'm sure you are able to find unique selling points without going into > >> >> any part of competition with Plasma or in any part which could be > >> >> misunderstood. > >> >> > >> >> What I do not want is Phoronix: "KDE starts new desktop shell because > >> >> Plasma sucks". Please formulate everything so that it cannot be > >> >> misunderstood. > >> >> > >> >> Also remove all the parts about the main motivation without "hog cpu > >> >> or > >> >> ram". We already discussed that this was a problem with your local and > >> >> personal setup. Don't piss on Plasma because your setup has problems. > >> >> You have all the rights to scratch your own itch, but don't piss on > >> >> us. > >> >> > >> >> Personally I'm against liquidshell getting added to extragear. I think > >> >> this would be harming the KDE community to have a shared desktop > >> >> shell. > >> >> We have already too much fragmentation on the desktop area and I don't > >> >> think KDE should support this by creating yet another desktop shell. > >> >> We > >> >> should think here in the big picture. > >> > > >> > So you'd rather prefer he did this in github? > >> > >> I did't write that and I'm surprised you come to that conclusion. > > > > You said we should not take this in. Martin wants this to be published > > it > > somehwere, so it has to end up somewhere in github or similar. That was > > my > > conclusion, i really don't see how is it surprising? > > Yes, I think we should not take it into extra-gear. That does not mean > that I have anything against it being hosted on KDE's git > infrastructure. Whether it gets released and promoted by the KDE > community is rather orthogonal to where it is hosted. > > So I don't understand your reasoning. There's no such thing as extregear anymore (well there is in the l10n module sense but we should be trying to get rid of it) Conceptually, there is: * stuff hosted in KDE and released as a "group", i.e. - Plasma - KDE Frameworks - "KDE Applications" [1] * stuff hosted in KDE and released individually [2] - Krita - rsibreak - kaffeine - konversation - etc So I don't understand your reasoning. Are you suggesting that we can host something in kde repos and it gets released by a kde person but still not be a kde project? Cheers, Albert [1] yes we all agree it's a bad name but noone has come up with a better one [2] formerly known as extragear
Re: liquidshell in kdereview
Am 2017-12-03 12:28, schrieb Albert Astals Cid: El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va escriure: Am 2017-12-02 10:17, schrieb Albert Astals Cid: > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va > > escriure: >> Am 2017-11-29 21:23, schrieb Martin Koller: >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: >> >> Hi all, >> >> >> >> I'd like to announce an application I've implemented over the last few >> >> weeks - liquidshell >> > >> > since more than 3 weeks have passed, I hopefully have addressed all >> > issues and I got no further comments, >> > are there any blocking points you see or can I proceed requesting the >> > move to extragear ? >> >> Yes I still see several blocking items. E.g. >> "liquidshell is an alternative to plasmashell" >> >> I think that should be removed. I do not want any competing or >> alternative to plasmashell provided by KDE. This would be very bad for >> our community. Please formulate the readme without mentioning Plasma. >> I'm sure you are able to find unique selling points without going into >> any part of competition with Plasma or in any part which could be >> misunderstood. >> >> What I do not want is Phoronix: "KDE starts new desktop shell because >> Plasma sucks". Please formulate everything so that it cannot be >> misunderstood. >> >> Also remove all the parts about the main motivation without "hog cpu >> or >> ram". We already discussed that this was a problem with your local and >> personal setup. Don't piss on Plasma because your setup has problems. >> You have all the rights to scratch your own itch, but don't piss on >> us. >> >> Personally I'm against liquidshell getting added to extragear. I think >> this would be harming the KDE community to have a shared desktop >> shell. >> We have already too much fragmentation on the desktop area and I don't >> think KDE should support this by creating yet another desktop shell. >> We >> should think here in the big picture. > > So you'd rather prefer he did this in github? I did't write that and I'm surprised you come to that conclusion. You said we should not take this in. Martin wants this to be published it somehwere, so it has to end up somewhere in github or similar. That was my conclusion, i really don't see how is it surprising? Yes, I think we should not take it into extra-gear. That does not mean that I have anything against it being hosted on KDE's git infrastructure. Whether it gets released and promoted by the KDE community is rather orthogonal to where it is hosted. So I don't understand your reasoning. > I mean yes, ideally everyone would work on whathever i want them to > work on, > but since this won't happen, can we try to make KDE a nice and > welcoming place > to challenge eachother ideas and implementations? > > I'm sure a little friendly (and yes this goes both ways in the > meanthing that > liquidshell should not piss on plasmashell) competition never hurt > anyone :) Such competition exists - especially on the desktop shell area, especially on the QtQuick vs. QtWidgets area. There currently are the following Qt based desktop shells: * Plasma (QtQuick) * LxQt (QtWidgets) * Lumina (QtWidgets) * Hawaii (QtQuick AFAIK) In addition there is competition in the GTK world: * GNOME Shell * Pantheon * Xfce * Budgie * Cinnamon And there are even further desktop environments on even other toolkits such as E. If there are things we need, it's yet another desktop environment. There is already sufficient external competition, so that we don't need internal competition. As I already said: Martin is free to do in his spare time whatever he wants. If he thinks we need another desktop shell, fine. He can do so. Whether we as KDE should endorse and support this is another question. I think for the overall Linux world yet another desktop shell is harming. You can have another opinion and that and that's also fine. I only shared my opinion stating that I consider this as harming and that we as KDE should IMHO not support this. Btw. I would see this completely different if for example LxQt would approach KDE and ask for joining. I would support this and would be happy to see them becoming a part of KDE. Also I think the project should not be added as the whole thing is hypocrite. According to the readme Martin has a problem with QtQuick. Fair enough, but why is he fine with the following areas being in QtQuick: * KWin (e.g. Alt+Tab) * Lockscreen * logout screen * Systemsettings * many more components If QtQuick would be a problem, Martin would have to replace everything and not just Plasmashell. *If* (big if) QtQuick had performance problems I would understand using QtQuick in the alt+tab/lockscreen/etc to be less problematic since i'm not using them all the time compared to Plasma itself. If QtQuick is a problem and causes high CPU usage that would especially be a problem whe
Re: liquidshell in kdereview
El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va escriure: > Am 2017-12-02 10:17, schrieb Albert Astals Cid: > > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va > > > > escriure: > >> Am 2017-11-29 21:23, schrieb Martin Koller: > >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > >> >> Hi all, > >> >> > >> >> I'd like to announce an application I've implemented over the last few > >> >> weeks - liquidshell > >> > > >> > since more than 3 weeks have passed, I hopefully have addressed all > >> > issues and I got no further comments, > >> > are there any blocking points you see or can I proceed requesting the > >> > move to extragear ? > >> > >> Yes I still see several blocking items. E.g. > >> "liquidshell is an alternative to plasmashell" > >> > >> I think that should be removed. I do not want any competing or > >> alternative to plasmashell provided by KDE. This would be very bad for > >> our community. Please formulate the readme without mentioning Plasma. > >> I'm sure you are able to find unique selling points without going into > >> any part of competition with Plasma or in any part which could be > >> misunderstood. > >> > >> What I do not want is Phoronix: "KDE starts new desktop shell because > >> Plasma sucks". Please formulate everything so that it cannot be > >> misunderstood. > >> > >> Also remove all the parts about the main motivation without "hog cpu > >> or > >> ram". We already discussed that this was a problem with your local and > >> personal setup. Don't piss on Plasma because your setup has problems. > >> You have all the rights to scratch your own itch, but don't piss on > >> us. > >> > >> Personally I'm against liquidshell getting added to extragear. I think > >> this would be harming the KDE community to have a shared desktop > >> shell. > >> We have already too much fragmentation on the desktop area and I don't > >> think KDE should support this by creating yet another desktop shell. > >> We > >> should think here in the big picture. > > > > So you'd rather prefer he did this in github? > > I did't write that and I'm surprised you come to that conclusion. You said we should not take this in. Martin wants this to be published it somehwere, so it has to end up somewhere in github or similar. That was my conclusion, i really don't see how is it surprising? > > > I mean yes, ideally everyone would work on whathever i want them to > > work on, > > but since this won't happen, can we try to make KDE a nice and > > welcoming place > > to challenge eachother ideas and implementations? > > > > I'm sure a little friendly (and yes this goes both ways in the > > meanthing that > > liquidshell should not piss on plasmashell) competition never hurt > > anyone :) > > Such competition exists - especially on the desktop shell area, > especially on the QtQuick vs. QtWidgets area. > > There currently are the following Qt based desktop shells: > * Plasma (QtQuick) > * LxQt (QtWidgets) > * Lumina (QtWidgets) > * Hawaii (QtQuick AFAIK) > > In addition there is competition in the GTK world: > * GNOME Shell > * Pantheon > * Xfce > * Budgie > * Cinnamon > > And there are even further desktop environments on even other toolkits > such as E. > > If there are things we need, it's yet another desktop environment. There > is already sufficient external competition, so that we don't need > internal competition. > > As I already said: Martin is free to do in his spare time whatever he > wants. If he thinks we need another desktop shell, fine. He can do so. > Whether we as KDE should endorse and support this is another question. > > I think for the overall Linux world yet another desktop shell is > harming. You can have another opinion and that and that's also fine. I > only shared my opinion stating that I consider this as harming and that > we as KDE should IMHO not support this. > > Btw. I would see this completely different if for example LxQt would > approach KDE and ask for joining. I would support this and would be > happy to see them becoming a part of KDE. > > Also I think the project should not be added as the whole thing is > hypocrite. According to the readme Martin has a problem with QtQuick. > Fair enough, but why is he fine with the following areas being in > QtQuick: > * KWin (e.g. Alt+Tab) > * Lockscreen > * logout screen > * Systemsettings > * many more components > > If QtQuick would be a problem, Martin would have to replace everything > and not just Plasmashell. *If* (big if) QtQuick had performance problems I would understand using QtQuick in the alt+tab/lockscreen/etc to be less problematic since i'm not using them all the time compared to Plasma itself. > I cannot help it, but I personally have a > feeling that Martin did not properly understand where his problems with > his system are. This means the motivation and argumentation is just > wrong. I don't think we as
Re: liquidshell in kdereview
Am 2017-12-02 10:17, schrieb Albert Astals Cid: El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va escriure: Am 2017-11-29 21:23, schrieb Martin Koller: > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: >> Hi all, >> >> I'd like to announce an application I've implemented over the last few >> weeks - liquidshell > > since more than 3 weeks have passed, I hopefully have addressed all > issues and I got no further comments, > are there any blocking points you see or can I proceed requesting the > move to extragear ? Yes I still see several blocking items. E.g. "liquidshell is an alternative to plasmashell" I think that should be removed. I do not want any competing or alternative to plasmashell provided by KDE. This would be very bad for our community. Please formulate the readme without mentioning Plasma. I'm sure you are able to find unique selling points without going into any part of competition with Plasma or in any part which could be misunderstood. What I do not want is Phoronix: "KDE starts new desktop shell because Plasma sucks". Please formulate everything so that it cannot be misunderstood. Also remove all the parts about the main motivation without "hog cpu or ram". We already discussed that this was a problem with your local and personal setup. Don't piss on Plasma because your setup has problems. You have all the rights to scratch your own itch, but don't piss on us. Personally I'm against liquidshell getting added to extragear. I think this would be harming the KDE community to have a shared desktop shell. We have already too much fragmentation on the desktop area and I don't think KDE should support this by creating yet another desktop shell. We should think here in the big picture. So you'd rather prefer he did this in github? I did't write that and I'm surprised you come to that conclusion. I mean yes, ideally everyone would work on whathever i want them to work on, but since this won't happen, can we try to make KDE a nice and welcoming place to challenge eachother ideas and implementations? I'm sure a little friendly (and yes this goes both ways in the meanthing that liquidshell should not piss on plasmashell) competition never hurt anyone :) Such competition exists - especially on the desktop shell area, especially on the QtQuick vs. QtWidgets area. There currently are the following Qt based desktop shells: * Plasma (QtQuick) * LxQt (QtWidgets) * Lumina (QtWidgets) * Hawaii (QtQuick AFAIK) In addition there is competition in the GTK world: * GNOME Shell * Pantheon * Xfce * Budgie * Cinnamon And there are even further desktop environments on even other toolkits such as E. If there are things we need, it's yet another desktop environment. There is already sufficient external competition, so that we don't need internal competition. As I already said: Martin is free to do in his spare time whatever he wants. If he thinks we need another desktop shell, fine. He can do so. Whether we as KDE should endorse and support this is another question. I think for the overall Linux world yet another desktop shell is harming. You can have another opinion and that and that's also fine. I only shared my opinion stating that I consider this as harming and that we as KDE should IMHO not support this. Btw. I would see this completely different if for example LxQt would approach KDE and ask for joining. I would support this and would be happy to see them becoming a part of KDE. Also I think the project should not be added as the whole thing is hypocrite. According to the readme Martin has a problem with QtQuick. Fair enough, but why is he fine with the following areas being in QtQuick: * KWin (e.g. Alt+Tab) * Lockscreen * logout screen * Systemsettings * many more components If QtQuick would be a problem, Martin would have to replace everything and not just Plasmashell. I cannot help it, but I personally have a feeling that Martin did not properly understand where his problems with his system are. This means the motivation and argumentation is just wrong. I don't think we as KDE should support an ill taken path. We are a community which is proud about our technical abilities, always trying to be in the first front for new technologies. Do we really want to take in products which are motivated on technical misunderstandings? Cheers Martin Flöser
Re: liquidshell in kdereview
El dissabte, 2 de desembre de 2017, a les 11:52:53 CET, Sebastian Kügler va escriure: > On Sat, 02 Dec 2017 10:27:16 +0100 > > Albert Astals Cid wrote: > > El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian > > > > Kügler va escriure: > > > On Thu, 30 Nov 2017 18:41:28 +0100 > > > > > > Martin Koller wrote: > > > > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler > > > > > > > > wrote: > > > > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > > > > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I'd like to announce an application I've implemented over > > > > > > > the last few weeks - liquidshell > > > > > > > > > > > > since more than 3 weeks have passed, I hopefully have > > > > > > addressed all issues and I got no further comments, are there > > > > > > any blocking points you see or can I proceed requesting the > > > > > > move to extragear ? > > > > > > > > > > > > A note regarding the comment to not use the start-here-kde > > > > > > logo: I got in contact with the visual design group and got > > > > > > the information to stay with this logo. > > > > > > > > > > I strongly disagree. Could you point me to the discussion? > > > > > > > > it was mail exchange in private (german) mails with the > > > > breeze/oxygen-icons maintainer "kainz.a" > > > > > > In any case, this is not just a visual design question, it's a > > > branding and marketing question just as much, and a general > > > communication and positioning question as well. > > > > Yes, the logo has to be changed. > > > > > I'm vetoing any move to released software at the very least until > > > the logo has changed. I also don't think that a technical review of > > > the code is enough to warrant us to ship liquidshell as a finished > > > product, for the reasons that Martin Flöser pointed out. It would > > > harm KDE as a whole and Plasma specifically (ironically, the > > > product that you use most parts from). > > > > This is an interesting position, are we supposed to subordinate > > technical decisions to marketing now? > > We are doing a review not just based on the code, but based on "is this > suitable and a good idea for KDE to release in this way". It's not > purely marketing, but general communication. > > If I wrote a very simple application that just poppped up a Window that > said "Krita is crap", the code could technically be totally fine, but > it may still not be a good idea to do it. If Martin wants to release > this under the KDE umbrella, we should make sure we're not actively > harming other people working inside KDE. > > > Also are you even sure we get better marketing by not allowing > > liquidshell to be a KDE thing? > > > > I can very well see headlines like "Plasma developers force other KDE > > developers outside of KDE". > > > > I would like to empathize that we are at our core Innovation. > > > > And yes, I agree that doing a desktop shell in QWidgets doesn't seem > > like Innovation to me, but Innovation is the process of having new > > ideas and products. > > Absolutely, but it should also be advertised in a healthy way, and > liquidshell in its current form isn't. Ok, so we're on the same page :) Cheers, Albert
Re: liquidshell in kdereview
On Sat, 02 Dec 2017 10:27:16 +0100 Albert Astals Cid wrote: > El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian > Kügler va escriure: > > On Thu, 30 Nov 2017 18:41:28 +0100 > > > > Martin Koller wrote: > > > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler > > > wrote: > > > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > > > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > > > Hi all, > > > > > > > > > > > > I'd like to announce an application I've implemented over > > > > > > the last few weeks - liquidshell > > > > > > > > > > since more than 3 weeks have passed, I hopefully have > > > > > addressed all issues and I got no further comments, are there > > > > > any blocking points you see or can I proceed requesting the > > > > > move to extragear ? > > > > > > > > > > A note regarding the comment to not use the start-here-kde > > > > > logo: I got in contact with the visual design group and got > > > > > the information to stay with this logo. > > > > > > > > I strongly disagree. Could you point me to the discussion? > > > > > > it was mail exchange in private (german) mails with the > > > breeze/oxygen-icons maintainer "kainz.a" > > > > In any case, this is not just a visual design question, it's a > > branding and marketing question just as much, and a general > > communication and positioning question as well. > > Yes, the logo has to be changed. > > > > > I'm vetoing any move to released software at the very least until > > the logo has changed. I also don't think that a technical review of > > the code is enough to warrant us to ship liquidshell as a finished > > product, for the reasons that Martin Flöser pointed out. It would > > harm KDE as a whole and Plasma specifically (ironically, the > > product that you use most parts from). > > This is an interesting position, are we supposed to subordinate > technical decisions to marketing now? We are doing a review not just based on the code, but based on "is this suitable and a good idea for KDE to release in this way". It's not purely marketing, but general communication. If I wrote a very simple application that just poppped up a Window that said "Krita is crap", the code could technically be totally fine, but it may still not be a good idea to do it. If Martin wants to release this under the KDE umbrella, we should make sure we're not actively harming other people working inside KDE. > Also are you even sure we get better marketing by not allowing > liquidshell to be a KDE thing? > > I can very well see headlines like "Plasma developers force other KDE > developers outside of KDE". > > I would like to empathize that we are at our core Innovation. > > And yes, I agree that doing a desktop shell in QWidgets doesn't seem > like Innovation to me, but Innovation is the process of having new > ideas and products. Absolutely, but it should also be advertised in a healthy way, and liquidshell in its current form isn't. > Maybe this one has great "external" success and against your and my > prediction gives KDE 1000 new developers that besides contributing to > it also end up contributing to other parts of our software range. > > Let's try to think positive :) That's the point Martin Flöser already made: liquidshell should be advertised based on its merits, not based on "plasmashell is shit, here's something better (I think)" Cheers, -- sebas
Re: liquidshell in kdereview
El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian Kügler va escriure: > On Thu, 30 Nov 2017 18:41:28 +0100 > > Martin Koller wrote: > > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote: > > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > > Hi all, > > > > > > > > > > I'd like to announce an application I've implemented over the > > > > > last few weeks - liquidshell > > > > > > > > since more than 3 weeks have passed, I hopefully have addressed > > > > all issues and I got no further comments, are there any blocking > > > > points you see or can I proceed requesting the move to extragear ? > > > > > > > > A note regarding the comment to not use the start-here-kde logo: > > > > I got in contact with the visual design group and got the > > > > information to stay with this logo. > > > > > > I strongly disagree. Could you point me to the discussion? > > > > it was mail exchange in private (german) mails with the > > breeze/oxygen-icons maintainer "kainz.a" > > In any case, this is not just a visual design question, it's a branding > and marketing question just as much, and a general communication and > positioning question as well. Yes, the logo has to be changed. > > I'm vetoing any move to released software at the very least until the > logo has changed. I also don't think that a technical review of the > code is enough to warrant us to ship liquidshell as a finished product, > for the reasons that Martin Flöser pointed out. It would harm KDE as a > whole and Plasma specifically (ironically, the product that you use > most parts from). This is an interesting position, are we supposed to subordinate technical decisions to marketing now? Also are you even sure we get better marketing by not allowing liquidshell to be a KDE thing? I can very well see headlines like "Plasma developers force other KDE developers outside of KDE". I would like to empathize that we are at our core Innovation. And yes, I agree that doing a desktop shell in QWidgets doesn't seem like Innovation to me, but Innovation is the process of having new ideas and products. Maybe this one has great "external" success and against your and my prediction gives KDE 1000 new developers that besides contributing to it also end up contributing to other parts of our software range. Let's try to think positive :) Cheers, Albert > > Cheers, > > -- sebas
Re: liquidshell in kdereview
El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va escriure: > Am 2017-11-29 21:23, schrieb Martin Koller: > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > >> Hi all, > >> > >> I'd like to announce an application I've implemented over the last few > >> weeks - liquidshell > > > > since more than 3 weeks have passed, I hopefully have addressed all > > issues and I got no further comments, > > are there any blocking points you see or can I proceed requesting the > > move to extragear ? > > Yes I still see several blocking items. E.g. > "liquidshell is an alternative to plasmashell" > > I think that should be removed. I do not want any competing or > alternative to plasmashell provided by KDE. This would be very bad for > our community. Please formulate the readme without mentioning Plasma. > I'm sure you are able to find unique selling points without going into > any part of competition with Plasma or in any part which could be > misunderstood. > > What I do not want is Phoronix: "KDE starts new desktop shell because > Plasma sucks". Please formulate everything so that it cannot be > misunderstood. > > Also remove all the parts about the main motivation without "hog cpu or > ram". We already discussed that this was a problem with your local and > personal setup. Don't piss on Plasma because your setup has problems. > You have all the rights to scratch your own itch, but don't piss on us. > > Personally I'm against liquidshell getting added to extragear. I think > this would be harming the KDE community to have a shared desktop shell. > We have already too much fragmentation on the desktop area and I don't > think KDE should support this by creating yet another desktop shell. We > should think here in the big picture. So you'd rather prefer he did this in github? I mean yes, ideally everyone would work on whathever i want them to work on, but since this won't happen, can we try to make KDE a nice and welcoming place to challenge eachother ideas and implementations? I'm sure a little friendly (and yes this goes both ways in the meanthing that liquidshell should not piss on plasmashell) competition never hurt anyone :) Cheers, Albert > > Cheers > Martin
Re: liquidshell in kdereview
On Thu, 30 Nov 2017 18:41:28 +0100 Martin Koller wrote: > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote: > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > > > > > > > Hi all, > > > > > > > > I'd like to announce an application I've implemented over the > > > > last few weeks - liquidshell > > > since more than 3 weeks have passed, I hopefully have addressed > > > all issues and I got no further comments, are there any blocking > > > points you see or can I proceed requesting the move to extragear ? > > > > > > A note regarding the comment to not use the start-here-kde logo: > > > I got in contact with the visual design group and got the > > > information to stay with this logo. > > > > I strongly disagree. Could you point me to the discussion? > > it was mail exchange in private (german) mails with the > breeze/oxygen-icons maintainer "kainz.a" In any case, this is not just a visual design question, it's a branding and marketing question just as much, and a general communication and positioning question as well. I'm vetoing any move to released software at the very least until the logo has changed. I also don't think that a technical review of the code is enough to warrant us to ship liquidshell as a finished product, for the reasons that Martin Flöser pointed out. It would harm KDE as a whole and Plasma specifically (ironically, the product that you use most parts from). Cheers, -- sebas
Re: liquidshell in kdereview
Am 2017-11-29 21:23, schrieb Martin Koller: On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: Hi all, I'd like to announce an application I've implemented over the last few weeks - liquidshell since more than 3 weeks have passed, I hopefully have addressed all issues and I got no further comments, are there any blocking points you see or can I proceed requesting the move to extragear ? Yes I still see several blocking items. E.g. "liquidshell is an alternative to plasmashell" I think that should be removed. I do not want any competing or alternative to plasmashell provided by KDE. This would be very bad for our community. Please formulate the readme without mentioning Plasma. I'm sure you are able to find unique selling points without going into any part of competition with Plasma or in any part which could be misunderstood. What I do not want is Phoronix: "KDE starts new desktop shell because Plasma sucks". Please formulate everything so that it cannot be misunderstood. Also remove all the parts about the main motivation without "hog cpu or ram". We already discussed that this was a problem with your local and personal setup. Don't piss on Plasma because your setup has problems. You have all the rights to scratch your own itch, but don't piss on us. Personally I'm against liquidshell getting added to extragear. I think this would be harming the KDE community to have a shared desktop shell. We have already too much fragmentation on the desktop area and I don't think KDE should support this by creating yet another desktop shell. We should think here in the big picture. Cheers Martin
Re: liquidshell in kdereview
Am 2017-11-29 21:23, schrieb Martin Koller: On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: Hi all, I'd like to announce an application I've implemented over the last few weeks - liquidshell since more than 3 weeks have passed, I hopefully have addressed all issues and I got no further comments, are there any blocking points you see or can I proceed requesting the move to extragear ? A note regarding the comment to not use the start-here-kde logo: I got in contact with the visual design group and got the information to stay with this logo. Like sebas I also strongly disagree. This would be highly confusing. If Plasma doesn't use the KDE icon another desktop shell shouldn't use KDE icon as well. I strongly suggest to use a different icon, just to make it clear that this is not the official KDE desktop shell. Cheers Martin
Re: liquidshell in kdereview
On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote: > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > > > > Hi all, > > > > > > I'd like to announce an application I've implemented over the last few > > > weeks - liquidshell > > since more than 3 weeks have passed, I hopefully have addressed all issues > > and I got no further comments, are there any blocking points you see or can > > I proceed requesting the move to extragear ? > > > > A note regarding the comment to not use the start-here-kde logo: > > I got in contact with the visual design group and got the information to > > stay with this logo. > > I strongly disagree. Could you point me to the discussion? it was mail exchange in private (german) mails with the breeze/oxygen-icons maintainer "kainz.a" -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > Hi all, > > > > I'd like to announce an application I've implemented over the last few > > weeks - liquidshell > since more than 3 weeks have passed, I hopefully have addressed all issues > and I got no further comments, are there any blocking points you see or can > I proceed requesting the move to extragear ? > > A note regarding the comment to not use the start-here-kde logo: > I got in contact with the visual design group and got the information to > stay with this logo. I strongly disagree. Could you point me to the discussion? -- sebas http://www.kde.org | http://vizZzion.org
Re: liquidshell in kdereview
On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > Hi all, > > I'd like to announce an application I've implemented over the last few weeks > - liquidshell since more than 3 weeks have passed, I hopefully have addressed all issues and I got no further comments, are there any blocking points you see or can I proceed requesting the move to extragear ? A note regarding the comment to not use the start-here-kde logo: I got in contact with the visual design group and got the information to stay with this logo. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: Recommended modesetting driver for Intel graphic cards (was: Re: liquidshell in kdereview)
On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau wrote: > Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker: > > On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote: > > > Am 2017-11-07 20:08, schrieb Martin Koller: > > > >> Are you aware that KWin uses QtQuick for all its UI elements, such as > > > >> Alt+TAB? > > > > > > > > I have deactivated the compositor since sadly it simply does not work > > > > on my laptop (the intel graphics driver just freezes the whole > > > > machine). > > > > > > I did not talk about compositor, I talked about QtQuick! Yes, KWin uses > > > QtQuick for rendering it's UI, that is unrelated to compositing. > > > > > > Now you mention that your intel graphics driver freezes the whole > > > system. I'm using Intel on all my systems and it's the most used driver > > > out there. We get many, many, many bug reports in KWin about issues. > > > Freezing systems has not been in the list for now something like two > > > years. > > > > > > Given that I am very certain that you have a hardware issue where people > > > can help you with. Intel GPUs are good enough to run the Plasma session > > > without any negative impact. > > > > > > So let us help you fix your issues that you can enjoy our work without > > > having to spend time on writing your own shell. > > > > > > First thing: are you using the xorg-modesettings driver? If not: install > > > it, problems solved. Do not (I repeat) do not use the xorg-intel driver. > > > > > > For kernel I recommend at least version 4.13 as this comes with the > > > atomic modesettings driver stack enabled by default. If you do not have > > > such a kernel version yet I highly recommend to give it a try. > > > > Martin, thanks a lot for your advice! > > > > I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed > > some time ago (and much longer on my laptop where I've switched to Leap > > and > > later Tumbleweed much earlier). > > Same here, happy to finally see someone with correlated experience. I never > got any useful hints in the log files, so was close to consider my hardware > broken. Strange enough all freezes seemed to happen while moving the mouse > though, which kept the hope alive it was something software-related. > > Curious to see if my daily freeze will now be a thing of the past now that I > changed the driver. Though I am on a 2nd gen 915 device, while all the > modesettings driver talk I came across on a quick search seemed to be only > about gen4 and later? No issues seen for one hour so far, hope grows :) > > The switch to the modesetting driver seems > > to have fixed those issues. It took me some time to find out how to enable > > the modesetting driver. To save others the time here's how to do it: Write > > #= > > Section "Device" > > > >Identifier "Intel Graphics" > >Driver "modesetting" > > > > EndSection > > #= > > to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that > > this is the only (or at least the first) "Device" section in any of the > > files in /etc/X11/xorg.conf.d/. > > Another approach seems to be to uninstall xf86-video-intel, that way the > seemingly hardcoded driver-auto-match logic will skip forward to the > modesetting driver: > > [12.125] (==) Matched intel as autoconfigured driver 0 > [12.125] (==) Matched intel as autoconfigured driver 1 > [12.125] (==) Matched modesetting as autoconfigured driver 2 > [12.125] (==) Matched fbdev as autoconfigured driver 3 > [12.125] (==) Matched vesa as autoconfigured driver 4 > [12.125] (==) Assigned the driver to the xf86ConfigLayout > [12.125] (II) LoadModule: "intel" > [12.127] (WW) Warning, couldn't open module intel > [12.127] (II) UnloadModule: "intel" > [12.127] (II) Unloading intel > [12.127] (EE) Failed to load module "intel" (module does not exist, 0) > [12.127] (II) LoadModule: "modesetting" > [12.127] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so I've also recently come across this. According to [1] the performance is supposedly much worse. Is this still true for more recent mesa/kernel versions? [1]: https://www.phoronix.com/scan.php?page=news_item&px=Intel-DDX-May-Tests Thanks, I'll have to try this out -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Recommended modesetting driver for Intel graphic cards (was: Re: liquidshell in kdereview)
Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker: > On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote: > > Am 2017-11-07 20:08, schrieb Martin Koller: > > >> Are you aware that KWin uses QtQuick for all its UI elements, such as > > >> Alt+TAB? > > > > > > I have deactivated the compositor since sadly it simply does not work > > > on my laptop (the intel graphics driver just freezes the whole > > > machine). > > > > I did not talk about compositor, I talked about QtQuick! Yes, KWin uses > > QtQuick for rendering it's UI, that is unrelated to compositing. > > > > Now you mention that your intel graphics driver freezes the whole > > system. I'm using Intel on all my systems and it's the most used driver > > out there. We get many, many, many bug reports in KWin about issues. > > Freezing systems has not been in the list for now something like two > > years. > > > > Given that I am very certain that you have a hardware issue where people > > can help you with. Intel GPUs are good enough to run the Plasma session > > without any negative impact. > > > > So let us help you fix your issues that you can enjoy our work without > > having to spend time on writing your own shell. > > > > First thing: are you using the xorg-modesettings driver? If not: install > > it, problems solved. Do not (I repeat) do not use the xorg-intel driver. > > > > For kernel I recommend at least version 4.13 as this comes with the > > atomic modesettings driver stack enabled by default. If you do not have > > such a kernel version yet I highly recommend to give it a try. > > Martin, thanks a lot for your advice! > > I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed > some time ago (and much longer on my laptop where I've switched to Leap and > later Tumbleweed much earlier). Same here, happy to finally see someone with correlated experience. I never got any useful hints in the log files, so was close to consider my hardware broken. Strange enough all freezes seemed to happen while moving the mouse though, which kept the hope alive it was something software-related. Curious to see if my daily freeze will now be a thing of the past now that I changed the driver. Though I am on a 2nd gen 915 device, while all the modesettings driver talk I came across on a quick search seemed to be only about gen4 and later? No issues seen for one hour so far, hope grows :) > The switch to the modesetting driver seems > to have fixed those issues. It took me some time to find out how to enable > the modesetting driver. To save others the time here's how to do it: Write > #= > Section "Device" >Identifier "Intel Graphics" >Driver "modesetting" > EndSection > #= > to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that this > is the only (or at least the first) "Device" section in any of the files in > /etc/X11/xorg.conf.d/. Another approach seems to be to uninstall xf86-video-intel, that way the seemingly hardcoded driver-auto-match logic will skip forward to the modesetting driver: [12.125] (==) Matched intel as autoconfigured driver 0 [12.125] (==) Matched intel as autoconfigured driver 1 [12.125] (==) Matched modesetting as autoconfigured driver 2 [12.125] (==) Matched fbdev as autoconfigured driver 3 [12.125] (==) Matched vesa as autoconfigured driver 4 [12.125] (==) Assigned the driver to the xf86ConfigLayout [12.125] (II) LoadModule: "intel" [12.127] (WW) Warning, couldn't open module intel [12.127] (II) UnloadModule: "intel" [12.127] (II) Unloading intel [12.127] (EE) Failed to load module "intel" (module does not exist, 0) [12.127] (II) LoadModule: "modesetting" [12.127] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so Cheers Friedrich
Re: liquidshell in kdereview
On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote: > Am 2017-11-07 20:08, schrieb Martin Koller: > >> Are you aware that KWin uses QtQuick for all its UI elements, such as > >> Alt+TAB? > > > > I have deactivated the compositor since sadly it simply does not work > > on my laptop (the intel graphics driver just freezes the whole > > machine). > > I did not talk about compositor, I talked about QtQuick! Yes, KWin uses > QtQuick for rendering it's UI, that is unrelated to compositing. > > Now you mention that your intel graphics driver freezes the whole > system. I'm using Intel on all my systems and it's the most used driver > out there. We get many, many, many bug reports in KWin about issues. > Freezing systems has not been in the list for now something like two > years. > > Given that I am very certain that you have a hardware issue where people > can help you with. Intel GPUs are good enough to run the Plasma session > without any negative impact. > > So let us help you fix your issues that you can enjoy our work without > having to spend time on writing your own shell. > > First thing: are you using the xorg-modesettings driver? If not: install > it, problems solved. Do not (I repeat) do not use the xorg-intel driver. > > For kernel I recommend at least version 4.13 as this comes with the > atomic modesettings driver stack enabled by default. If you do not have > such a kernel version yet I highly recommend to give it a try. Martin, thanks a lot for your advice! I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed some time ago (and much longer on my laptop where I've switched to Leap and later Tumbleweed much earlier). The switch to the modesetting driver seems to have fixed those issues. It took me some time to find out how to enable the modesetting driver. To save others the time here's how to do it: Write #= Section "Device" Identifier "Intel Graphics" Driver "modesetting" EndSection #= to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that this is the only (or at least the first) "Device" section in any of the files in /etc/X11/xorg.conf.d/. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: liquidshell in kdereview
On Donnerstag, 9. November 2017 15:32:46 CET Friedrich W. H. Kossebau wrote: > Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller: > > On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote: > > > Am 2017-11-03 21:30, schrieb Martin Koller: > > > I don't mind what you develop in your spare time. Not at all. What I > > > mind is if a product is added to KDE as a competitor/replacement to a > > > product I work on because of misunderstood things. What I see here is > > > that you completely misunderstood what hardware acceleration means and > > > gives to the system. > > > > See above. I did not start liquidshell because I was bored. Believe me, I > > have other hobbies. I started it just because I got fed up with the > > problems I had with plasmashell and I need to use some DE for my daily > > work. Restarting plasmashell multiple times a day is just not funny. > > I think what Martin F. is also asking here, and what surely one expects as > standard in KDE, is that the description of the liquidshell product/project > is > not making false or unresearched claims I did not make false or unresearched claims. QPainter, wich is the base for drawing in QWidgets, is - AFAIK - not using hardware acceleration. At least inside Qt. Martin F. just explained that deep down in the graphics stack there is still acceleration used, but that was not my point. > or speaking badly about alternative solutions, especially from the same > community. > In short: being respectful :) > So e.g. if this was about some new liquidhexeditor, I as author of Okteta > would be not happy about phrases like: > > * "liquidhexeditor is a replacement for okteta" > "replacement" (to me) comes with meaning of successor, being better. Which is > attributing things. > The more neutral word "alternative" might be better here. will change > * "It does not use QtQuick but instead relies on QtWidgets." > "not use X but relies on Y" also tells me that "X" sucks and better is > avoided. > Where one could rather say "Uses X for everything because property 1, > property > 2 and property 3", without losing a word about "Y". Just listing the factors > one made their choice on for using "X" leaves everyone with their idea about > the qualities of "Y". > E.g. it could be said that QWidgets are a stable mature UI technology and > (like already is sayed) provide a consistent UI across shell and apps (at > least the QWidget-based apps). > No need to speak here about alternatives like QQ, Gtk, or EFL, there are > people for any who think that to be a better base to build a UI on. the major difference between plasmashell and liquidshell IS the non-usage of QtQuick, therefore it definitely needs to be mentioned. That does not imply judgement. It's just an explanation of what technology it uses and which it does not - given that these are the two major possibilities from Qt. I have adjusted the README > BTW, you are surely aware that other UI components of the Plasma workspace, > like the System Settings, are ported to QtQuick currently. So given your > implementation choices, do you plan to create a liquidsystemsettings variant > as well? not planned -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller: > On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote: > > Am 2017-11-03 21:30, schrieb Martin Koller: > > I don't mind what you develop in your spare time. Not at all. What I > > mind is if a product is added to KDE as a competitor/replacement to a > > product I work on because of misunderstood things. What I see here is > > that you completely misunderstood what hardware acceleration means and > > gives to the system. > > See above. I did not start liquidshell because I was bored. Believe me, I > have other hobbies. I started it just because I got fed up with the > problems I had with plasmashell and I need to use some DE for my daily > work. Restarting plasmashell multiple times a day is just not funny. I think what Martin F. is also asking here, and what surely one expects as standard in KDE, is that the description of the liquidshell product/project is not making false or unresearched claims or speaking badly about alternative solutions, especially from the same community. In short: being respectful :) So e.g. if this was about some new liquidhexeditor, I as author of Okteta would be not happy about phrases like: * "liquidhexeditor is a replacement for okteta" "replacement" (to me) comes with meaning of successor, being better. Which is attributing things. The more neutral word "alternative" might be better here. * "It does not use QtQuick but instead relies on QtWidgets." "not use X but relies on Y" also tells me that "X" sucks and better is avoided. Where one could rather say "Uses X for everything because property 1, property 2 and property 3", without losing a word about "Y". Just listing the factors one made their choice on for using "X" leaves everyone with their idea about the qualities of "Y". E.g. it could be said that QWidgets are a stable mature UI technology and (like already is sayed) provide a consistent UI across shell and apps (at least the QWidget-based apps). No need to speak here about alternatives like QQ, Gtk, or EFL, there are people for any who think that to be a better base to build a UI on. So Martik K., IMHO the current README carries still some of the frustration you had experienced with the Plasma shell. While this has been part of your motivation for your work on a new solution, it could be now time to step back and to turn completely into positive thinking like most of the README already is, for a peaceful, cooperative co-existence :) I propose to start the README with the product requirements you had in mind when working on liquidshell, perhaps by listing the features already implemented (and then listing some which you still consider to add). With those, potential users might be able to see whether the requirements match those they are looking for themselves, and developers might be able to follow your decisions on why creating a separate project and on the technologies used for the implementation. BTW, you are surely aware that other UI components of the Plasma workspace, like the System Settings, are ported to QtQuick currently. So given your implementation choices, do you plan to create a liquidsystemsettings variant as well? Cheers Friedrich
Re: liquidshell in kdereview
Am Dienstag, 7. November 2017, 19:27:31 CET schrieb Martin Koller: > On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote: > > BTW, would you like assistance to have liquidshell covered on > > build.kde.org? Seems it is not there yet. > > Wow - didn't know that this exists. > Is this just for testing if it compiles or are packages released from there > ? It is for checking building with current state of other KDE software that is in the same dependency tree. As well as tracking unit tests results and other code quality measurements. No packages generated there, only automated testing done. Cheers Friedrich
Re: liquidshell in kdereview
Hello, Just by curiosity, I've tried your shell. It is quite similar to my plasmashell configuration. It works for me except that I get tons of messages like: "0 instead of 3 arguments to message {Memory Used: %1 MB (...} supplied before conversion." "0 instead of 2 arguments to message {Memory Free: %1 MB (...} supplied before conversion." "0 instead of 2 arguments to message {Swap Total: %1 MB (%...} supplied before conversion." "0 instead of 3 arguments to message {Swap Used: %1 MB (%2...} supplied before conversion." "0 instead of 2 arguments to message {Swap Free: %1 MB (%2...} supplied before conversion." "0 instead of 2 arguments to message {Net send/receive: %1...} supplied before conversion." "0 instead of 1 arguments to message {Net max used: %1 KB/...} supplied before conversion." "0 instead of 2 arguments to message {Memory Total: %1 MB ...} supplied before conversion." "0 instead of 3 arguments to message {Memory Used: %1 MB (...} supplied before conversion." "0 instead of 2 arguments to message {Memory Free: %1 MB (...} supplied before conversion." "0 instead of 2 arguments to message {Swap Total: %1 MB (%...} supplied before conversion." "0 instead of 3 arguments to message {Swap Used: %1 MB (%2...} supplied before conversion." "0 instead of 2 arguments to message {Swap Free: %1 MB (%2...} supplied before conversion." "0 instead of 2 arguments to message {Net send/receive: %1...} supplied before conversion." "0 instead of 1 arguments to message {Net max used: %1 KB/...} supplied before conversion." from the cpu load widget. [image: Imágenes integradas 1] Best regards. 2017-11-07 20:55 GMT+01:00 Martin Flöser : > Am 2017-11-07 20:08, schrieb Martin Koller: > >> Are you aware that KWin uses QtQuick for all its UI elements, such as >>> Alt+TAB? >>> >> >> I have deactivated the compositor since sadly it simply does not work >> on my laptop (the intel graphics driver just freezes the whole machine). >> > > I did not talk about compositor, I talked about QtQuick! Yes, KWin uses > QtQuick for rendering it's UI, that is unrelated to compositing. > > Now you mention that your intel graphics driver freezes the whole system. > I'm using Intel on all my systems and it's the most used driver out there. > We get many, many, many bug reports in KWin about issues. Freezing systems > has not been in the list for now something like two years. > > Given that I am very certain that you have a hardware issue where people > can help you with. Intel GPUs are good enough to run the Plasma session > without any negative impact. > > So let us help you fix your issues that you can enjoy our work without > having to spend time on writing your own shell. > > First thing: are you using the xorg-modesettings driver? If not: install > it, problems solved. Do not (I repeat) do not use the xorg-intel driver. > > For kernel I recommend at least version 4.13 as this comes with the atomic > modesettings driver stack enabled by default. If you do not have such a > kernel version yet I highly recommend to give it a try. > > As another possible solution I provide something very radical: use > Wayland. My experience is that the system works way more reliable and nicer > on Intel. I had several issues with Xorg and Intel, I have none on Wayland. > > Cheers > Martin >
Re: liquidshell in kdereview
Am 2017-11-07 20:08, schrieb Martin Koller: Are you aware that KWin uses QtQuick for all its UI elements, such as Alt+TAB? I have deactivated the compositor since sadly it simply does not work on my laptop (the intel graphics driver just freezes the whole machine). I did not talk about compositor, I talked about QtQuick! Yes, KWin uses QtQuick for rendering it's UI, that is unrelated to compositing. Now you mention that your intel graphics driver freezes the whole system. I'm using Intel on all my systems and it's the most used driver out there. We get many, many, many bug reports in KWin about issues. Freezing systems has not been in the list for now something like two years. Given that I am very certain that you have a hardware issue where people can help you with. Intel GPUs are good enough to run the Plasma session without any negative impact. So let us help you fix your issues that you can enjoy our work without having to spend time on writing your own shell. First thing: are you using the xorg-modesettings driver? If not: install it, problems solved. Do not (I repeat) do not use the xorg-intel driver. For kernel I recommend at least version 4.13 as this comes with the atomic modesettings driver stack enabled by default. If you do not have such a kernel version yet I highly recommend to give it a try. As another possible solution I provide something very radical: use Wayland. My experience is that the system works way more reliable and nicer on Intel. I had several issues with Xorg and Intel, I have none on Wayland. Cheers Martin
Re: liquidshell in kdereview
On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote: > Am 2017-11-03 21:30, schrieb Martin Koller: > > Hi all, > > > > I'd like to announce an application I've implemented over the last few > > weeks - liquidshell > > > > liquidshell is a replacement for plasmashell > > > > It does not use QtQuick but instead relies on QtWidgets, > > therefore no hardware graphics acceleration is needed. > > [snip] > > > The main motivation was to have a reliable desktop shell which does > > not hog the CPU or RAM. > > (CPU usage and stability were the things driving me mad with > > plasmashell) > > It should be slick and have just the features I need in my daily > > work. No need having all the bells and whistles anyone can think of. > > Just have a plain, solid, fast workhorse. > > I'm now playing devils advocate: which window manager are you using? personally I'm using kwin, since I only replaced plasmashell, but I assume this is irrelevant to what "shell" one is using. > If I understand correctly this is supposed to be a replacement for > plasmashell in Plasma, which would mean that you use KWin. yes > Are you aware that KWin uses QtQuick for all its UI elements, such as > Alt+TAB? I have deactivated the compositor since sadly it simply does not work on my laptop (the intel graphics driver just freezes the whole machine). > Isn't that also a memory and resource hog? not here. It's not in the top 10 processes of CPU or memory usage > Shouldn't you come up with a replacement for KWin as well? no (as long as it works good enough for me) > Also concerning no hardware graphics acceleration needed: who is going > to render your UI? Do you really think the QPainter API is the best and > most efficent to render a UI? Especially considering that in the end the > whole thing needs to be transferred to the GPU. Are you aware that the > compositor uses hardware acceleration to render the UI? If you don't use > a compositor: are you aware that XServer itself uses hardware > acceleration to render its UI (check glamor). Are you aware that if you > don't have hardware acceleration everything is going to be rendered > through llvmpipe? Do you really think QPainter is better than llvmpipe? > Because I - having worked with that stuff for years in a low level area > - doubt so. You're barking at the wrong tree. I don't care how it's done deep down in the stack. I can tell you that now with liquidshell my CPU uses 0% CPU most of the time, and starting plasmashell it's more - sometimes much, much more without changing anything in the workspace setup. That is simply not acceptable for me. If plasmashell would work better, I would not have created liquidshell in the first place. Just wanting to WORK with my system, which I simply could not with plasmashell. > I don't mind what you develop in your spare time. Not at all. What I > mind is if a product is added to KDE as a competitor/replacement to a > product I work on because of misunderstood things. What I see here is > that you completely misunderstood what hardware acceleration means and > gives to the system. See above. I did not start liquidshell because I was bored. Believe me, I have other hobbies. I started it just because I got fed up with the problems I had with plasmashell and I need to use some DE for my daily work. Restarting plasmashell multiple times a day is just not funny. > I know, I know more than 90 % and all the > "lightweight" people get this wrong. But you know what I observed more > and more over the last years: people praise Plasma for the fast speed, > responsiveness and low memory consumption. Why is that so, why do people > no longer consider our software as bloated? Because we use QML and we > use it well! For me it - sadly - got worse over time. > So if that gets added I want to have it made clear that this is not a > "lightweight" product Did you read "lightweight" anywhere in my README ? > and I don't want it to be advertised as not using > hardware acceleration. > I don't want to see what you list in the main > motivation. I did not know that I need permission from you for what motivates me > Because that will just result in people going all "KDE dev > develops new desktop shell, because Plasma is unreliable". which it is for me, sorry > If that happens it pisses me off! And that's what's going to happen the way > you > phrased it. And what would piss me even more of is if that is due to you > misunderstanding hardware acceleration. I removed now the "no hardware acceleration" sentence from my README, since I'm obviously too dumb to know what I write, sorry. To be clear: It was not the "no hardware acceleration" need which led me starting liquidshell, it was the troubles I had with plasmashell (and obviously with the hardware I'm using). And since I'm using QtWidgets since ages and have no QML experience, this was clearly the way to go for me. Trying to debug plasmashell to find the
Re: liquidshell in kdereview
On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote: > Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller: > > On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote: > > > > light color theme: > > > > http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark > > > > color > > > > theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png > > > > > > Please consider using a non-KDE logo on the start menu on representative/ > > > advertising screenshots (ideally some new liquidshell logo one, also to > > > help promoting it and building an identity). > > > Given the history meaning of the KDE logo as the logo of a desktop, using > > > the KDE logo will spoil the concerted effort of the rebranding done > > > (whether it was a good idea or not is too late to discuss) and only > > > continue the confusion, for no good. > > > > > > So with the Plasma workspaces having moved to the Plasma logo, leaving the > > > KDE logo for the community, liquidshell should have and use its own > > > dedicated logo as well. (and yes, the start-here-kde icons would need > > > renaming finally) > > I'm very bad at creating appealing graphics, therefore I used exiting icons > > where possible. > > Is there some KDE artist who is willing to create a new logo for me ? > > I recommend to follow https://vdesign.kde.org/how.html and poke the VDG > people > directly with your requirement. thanks, will do > > > Regarding the rebranding: does that mean KDE (the people behind the project) > > does not like to promote KDE ? > > Very confusing in my view. > > I really meant to show "that is a KDE (based) application" by using its logo > > - was not clear that this is not welcomed. > > Surely we want to promote KDE, the community :) Just, like e.g. apps like > Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the > community, they do it via the entry in the Help menu or in the About data. > Still they have their own logo/icon for showing off e.g. "he, it's me, > okular" > and have their logo/icon displayed as identifier. > > The start menu icon here serves a similar purpose usually, it shows "he, its > me, workspace product X/operating system Y". But not saying "I am done by A", > especially when A creates different variants of the product type. > > And with the history of "KDE" being once the name of a workspace product, > using its logo on the start menu like in the formerly named "KDE" product > could trigger the uninformed people to consider liquidshell being the new > "KDE". Adding to confusion and wasted resources in fighting those > misconception. > So better prevent from the start, so our time could be spent in bug fixing > instead. ok, understand. > BTW, would you like assistance to have liquidshell covered on build.kde.org? > Seems it is not there yet. Wow - didn't know that this exists. Is this just for testing if it compiles or are packages released from there ? I've currently uploaded a version to build.opensuse.org which compiles currently some openSuse versions. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
Am 2017-11-03 21:30, schrieb Martin Koller: Hi all, I'd like to announce an application I've implemented over the last few weeks - liquidshell liquidshell is a replacement for plasmashell It does not use QtQuick but instead relies on QtWidgets, therefore no hardware graphics acceleration is needed. [snip] The main motivation was to have a reliable desktop shell which does not hog the CPU or RAM. (CPU usage and stability were the things driving me mad with plasmashell) It should be slick and have just the features I need in my daily work. No need having all the bells and whistles anyone can think of. Just have a plain, solid, fast workhorse. I'm now playing devils advocate: which window manager are you using? If I understand correctly this is supposed to be a replacement for plasmashell in Plasma, which would mean that you use KWin. Are you aware that KWin uses QtQuick for all its UI elements, such as Alt+TAB? Isn't that also a memory and resource hog? Shouldn't you come up with a replacement for KWin as well? Also concerning no hardware graphics acceleration needed: who is going to render your UI? Do you really think the QPainter API is the best and most efficent to render a UI? Especially considering that in the end the whole thing needs to be transferred to the GPU. Are you aware that the compositor uses hardware acceleration to render the UI? If you don't use a compositor: are you aware that XServer itself uses hardware acceleration to render its UI (check glamor). Are you aware that if you don't have hardware acceleration everything is going to be rendered through llvmpipe? Do you really think QPainter is better than llvmpipe? Because I - having worked with that stuff for years in a low level area - doubt so. I don't mind what you develop in your spare time. Not at all. What I mind is if a product is added to KDE as a competitor/replacement to a product I work on because of misunderstood things. What I see here is that you completely misunderstood what hardware acceleration means and gives to the system. I know, I know more than 90 % and all the "lightweight" people get this wrong. But you know what I observed more and more over the last years: people praise Plasma for the fast speed, responsiveness and low memory consumption. Why is that so, why do people no longer consider our software as bloated? Because we use QML and we use it well! So if that gets added I want to have it made clear that this is not a "lightweight" product and I don't want it to be advertised as not using hardware acceleration. I don't want to see what you list in the main motivation. Because that will just result in people going all "KDE dev develops new desktop shell, because Plasma is unreliable". If that happens it pisses me off! And that's what's going to happen the way you phrased it. And what would piss me even more of is if that is due to you misunderstanding hardware acceleration. Cheers Martin KWin maintainer
Re: liquidshell in kdereview
Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller: > On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote: > > > light color theme: > > > http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark > > > color > > > theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png > > > > Please consider using a non-KDE logo on the start menu on representative/ > > advertising screenshots (ideally some new liquidshell logo one, also to > > help promoting it and building an identity). > > Given the history meaning of the KDE logo as the logo of a desktop, using > > the KDE logo will spoil the concerted effort of the rebranding done > > (whether it was a good idea or not is too late to discuss) and only > > continue the confusion, for no good. > > > > So with the Plasma workspaces having moved to the Plasma logo, leaving the > > KDE logo for the community, liquidshell should have and use its own > > dedicated logo as well. (and yes, the start-here-kde icons would need > > renaming finally) > I'm very bad at creating appealing graphics, therefore I used exiting icons > where possible. > Is there some KDE artist who is willing to create a new logo for me ? I recommend to follow https://vdesign.kde.org/how.html and poke the VDG people directly with your requirement. > Regarding the rebranding: does that mean KDE (the people behind the project) > does not like to promote KDE ? > Very confusing in my view. > I really meant to show "that is a KDE (based) application" by using its logo > - was not clear that this is not welcomed. Surely we want to promote KDE, the community :) Just, like e.g. apps like Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the community, they do it via the entry in the Help menu or in the About data. Still they have their own logo/icon for showing off e.g. "he, it's me, okular" and have their logo/icon displayed as identifier. The start menu icon here serves a similar purpose usually, it shows "he, its me, workspace product X/operating system Y". But not saying "I am done by A", especially when A creates different variants of the product type. And with the history of "KDE" being once the name of a workspace product, using its logo on the start menu like in the formerly named "KDE" product could trigger the uninformed people to consider liquidshell being the new "KDE". Adding to confusion and wasted resources in fighting those misconception. So better prevent from the start, so our time could be spent in bug fixing instead. BTW, would you like assistance to have liquidshell covered on build.kde.org? Seems it is not there yet. Cheers Friedrich
Re: liquidshell in kdereview
+1000 to what Friedrich said :) Cheers, Albert En lunes, 6 de noviembre de 2017 17:13:04 CET, Friedrich W. H. Kossebau escribió: Hi Martin, Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > I'd like to announce an application I've implemented over the last few weeks > - liquidshell Congrats to the achievement. It surely feels good to run a workspace one has created one themselves :) While myself I will choose Plasma over liquidshell due to my needs and expectations of certain features, I can see that liquidshell would satisfy those persons who need or want just a simple hard-coded shell following a well-known UI design & concept, yet stay with the usual tools and apps from the KDE software world, ideally perfectly integrated with the workspace (think filemanager, terminal, text editor, etc). People like obviously yourself :) So those persons might be surely happy about you sharing your work with them. My hopes for liquidshell as another project under the KDE community umbrella: * improvements for shared middleware, perhaps even introducing some more where it makes sense to share between Plasma, liquidshell & others (pushing for more clear UI-core separation, which in theory is for good) libtm might be one such thing, the weather data provider system also calls for being shared code with Plasma (and e.g. the Marble weather plugin) * another testing ground for protocols & standards in development * make more obvious that "KDE" is about a community, not a certain software * give perhaps remaining trinity desktop developers and other Plasma-no-Qt-jay-fans a new center for their goals and as result also new contributors for the shared middleware, tools and apps (at least for their current QtWidgets UI variant ;) ) Re: gosh, yet another workspace In a perfect world everybody would join work on the one true golden workspace solution, reality is that there is no such one-workspace-which-fits-all. Not to forget the mythical person-month issue. And if people rather go and write their own software instead of joining existing projects, it should be the projects asking themselves why they have not been attractive enough in the first place. Telling people instead "you should not do X, but Y" is rather the opposite of what Free Software is about. Even when first saying "Your are free, but". I applaud you, Martin, for managing to solve your needs yourself and for sharing the results with the rest of the world, instead of keeping them for yourself. And as KDE community we can feel honored you trust us to be the best place for further development of your software, instead of going github or elsewhere. Re: liquidshell as name When I read liquidshell I first thought about something very dynamic, highly animated. So not sure "liquid" is the best term to use in the name. But then we all know naming is hard, good luck with it :) Cheers Friedrich
Re: liquidshell in kdereview
Sorry for top postiing, stupid webmail. Almost all projects start as a one man project, if you reject those you're basically making impossible for them to grow. Cheers, Albert En lunes, 6 de noviembre de 2017 15:31:34 CET, Tomaz Canabrava escribió: On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev wrote: > 2017-11-06 14:16 GMT+03:00 Kevin Funk : >> You're free to work on whatever you like to of course, but to me this sounds >> like wasted effort. Your good incentives would be better spent with joining >> up >> with others aiming for the same (LxQt for instance). > > Hi, > > I had a bad impression of LxQt because: > 1. it didn't work for me out of the box, For many people kde applications don't work out of the box too. > 2. it consists of many components, it's hard to figure out which of > them are optional, Also true for kde applications. > 3. it has poor infrastructure compared to KDE, e.g. their i18n server > hadn't been working for about a year. I cant comment on that - but the project seems to be alive as there was a new release just last month with a lot of changes, also they use kf5 libraries where needed. > Thus liquidshell looks better to me than lxqt; joining an inferior > project is not a good idea. please refrain from using words like 'inferior' for a project as it's not helpful. Currently the whole code for liquidshell is done for one person, and we (as in the KDE Sc) suffer for a lot of good projects and ideas that as soon as the original developers get tired the project stalls, like Macaw Movie, Spectacle, Baloo and quite a few others - so I'm really afraid of a one-man-project that's basically what other many projects already do. About liquidshell, I tried but it didn't even compile on my machine (some issue with Solid) > --Alexander Potashev
Re: liquidshell in kdereview
On 2017 M11 6, Mon 10:03:05 CET Tomaz Canabrava wrote: > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller wrote: ... > > Whoever does not like plasmashell, for whatever reason. > > My reasons are mentioned in the README or the announcement mail. > > Free software is about choice, no ? > > It is, of course. Then, it's also about non-fragmentation, and you know, > human resources are spare. just speaking for myself: I don't feel qualified to contribute to plasma (QML, very flexible architecture, fancy design concepts, etc.), but I would feel qualified to send a patch for a simple QWidget-based desktop shell. Alex
Re: liquidshell in kdereview
On 2017 M11 6, Mon 19:13:36 CET Martin Koller wrote: > On Montag, 6. November 2017 10:03:05 CET Tomaz Canabrava wrote: > > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller wrote: > > > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > > > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > > > > Hi all, > > > > > > > > > > I'd like to announce an application I've implemented over the last > > > > > few > > > > > > weeks - liquidshell > > > > > > > > liquidshell is a replacement for plasmashell > > > > > > > > Hi Martin, > > > > I'm a bit confused, who is liquidshell for? > > > > > > Whoever does not like plasmashell, for whatever reason. > > > My reasons are mentioned in the README or the announcement mail. > > > Free software is about choice, no ? > > > > It is, of course. Then, it's also about non-fragmentation, and you know, > > human resources are spare. > > I know it's your time and your project and I will never tell you what to > > do, > > but considering that there's lxqt which exists basically for the same > > 'whatever reasons', why not help them instead of creating yet another > > desktop shell? > > lxqt say on their web page "The Lightweight Qt Desktop Environment" > > I don't want to create yet another Desktop Environment. > I was just unhappy with plasmashell, which liquidshell replaces I tried lxqt too once, and while nice, I found quite some things lacking, IIRC if because it replaces really a lot of things and not only plasmashell. So while joining forces with lxqt sounds very obvious, lxqt AFAIK has a much wider focus, so I can understand starting a project which is "just" a replacement for plasmashell. Alex
Re: liquidshell in kdereview
On Montag, 6. November 2017 17:12:31 CET Friedrich W. H. Kossebau wrote: > Hi Martin, > > Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > > I'd like to announce an application I've implemented over the last few weeks > > - liquidshell > > Congrats to the achievement. It surely feels good to run a workspace one has > created one themselves :) > > While myself I will choose Plasma over liquidshell due to my needs and > expectations of certain features, I can see that liquidshell would satisfy > those persons who need or want just a simple hard-coded shell following a > well-known UI design & concept, yet stay with the usual tools and apps from > the KDE software world, ideally perfectly integrated with the workspace > (think > filemanager, terminal, text editor, etc). People like obviously yourself :) > So > those persons might be surely happy about you sharing your work with them. > > My hopes for liquidshell as another project under the KDE community umbrella: > * improvements for shared middleware, perhaps even introducing some more > where it makes sense to share between Plasma, liquidshell & others > (pushing for more clear UI-core separation, which in theory is for good) > libtm might be one such thing, the weather data provider system also calls > for being shared code with Plasma (and e.g. the Marble weather plugin) > * another testing ground for protocols & standards in development > * make more obvious that "KDE" is about a community, not a certain software > * give perhaps remaining trinity desktop developers and other > Plasma-no-Qt-jay-fans a new center for their goals and as result also new > contributors for the shared middleware, tools and apps (at least for their > current QtWidgets UI variant ;) ) > > Re: gosh, yet another workspace > In a perfect world everybody would join work on the one true golden workspace > solution, reality is that there is no such one-workspace-which-fits-all. Not > to forget the mythical person-month issue. > > And if people rather go and write their own software instead of joining > existing projects, it should be the projects asking themselves why they have > not been attractive enough in the first place. > Telling people instead "you should not do X, but Y" is rather the opposite of > what Free Software is about. Even when first saying "Your are free, but". > > I applaud you, Martin, for managing to solve your needs yourself and for > sharing the results with the rest of the world, instead of keeping them for > yourself. > And as KDE community we can feel honored you trust us to be the best place > for > further development of your software, instead of going github or elsewhere. thanks for the appreciation > Re: liquidshell as name > When I read liquidshell I first thought about something very dynamic, highly > animated. So not sure "liquid" is the best term to use in the name. But then > we all know naming is hard, good luck with it :) This was a tough one. really not easy to select a sensible name. I was considering "solidshell" but Solid has already a meaning in the KDE world. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote: > Some more branding oriented nitpicks: > > Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > > - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual > > Desktops, Bluetooth, Network > > Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs" > being a concept which no longer exists at age of KDE Frameworks and Plasma. changed > > light color theme: > > http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark color > > theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png > > Please consider using a non-KDE logo on the start menu on representative/ > advertising screenshots (ideally some new liquidshell logo one, also to help > promoting it and building an identity). > Given the history meaning of the KDE logo as the logo of a desktop, using the > KDE logo will spoil the concerted effort of the rebranding done (whether it > was a good idea or not is too late to discuss) and only continue the > confusion, for no good. > > So with the Plasma workspaces having moved to the Plasma logo, leaving the > KDE > logo for the community, liquidshell should have and use its own dedicated > logo > as well. (and yes, the start-here-kde icons would need renaming finally) I'm very bad at creating appealing graphics, therefore I used exiting icons where possible. Is there some KDE artist who is willing to create a new logo for me ? Regarding the rebranding: does that mean KDE (the people behind the project) does not like to promote KDE ? Very confusing in my view. I really meant to show "that is a KDE (based) application" by using its logo - was not clear that this is not welcomed. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Montag, 6. November 2017 10:03:05 CET Tomaz Canabrava wrote: > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller wrote: > > > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > > > Hi all, > > > > > > > > I'd like to announce an application I've implemented over the last few > > weeks - liquidshell > > > > > > > > liquidshell is a replacement for plasmashell > > > > > > > > > > > > Hi Martin, > > > I'm a bit confused, who is liquidshell for? > > > > Whoever does not like plasmashell, for whatever reason. > > My reasons are mentioned in the README or the announcement mail. > > Free software is about choice, no ? > > > > It is, of course. Then, it's also about non-fragmentation, and you know, > human resources are spare. > I know it's your time and your project and I will never tell you what to > do, > but considering that there's lxqt which exists basically for the same > 'whatever reasons', why not help them instead of creating yet another > desktop shell? lxqt say on their web page "The Lightweight Qt Desktop Environment" I don't want to create yet another Desktop Environment. I was just unhappy with plasmashell, which liquidshell replaces -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
Some more branding oriented nitpicks: Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual > Desktops, Bluetooth, Network Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs" being a concept which no longer exists at age of KDE Frameworks and Plasma. > light color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark color > theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png Please consider using a non-KDE logo on the start menu on representative/ advertising screenshots (ideally some new liquidshell logo one, also to help promoting it and building an identity). Given the history meaning of the KDE logo as the logo of a desktop, using the KDE logo will spoil the concerted effort of the rebranding done (whether it was a good idea or not is too late to discuss) and only continue the confusion, for no good. So with the Plasma workspaces having moved to the Plasma logo, leaving the KDE logo for the community, liquidshell should have and use its own dedicated logo as well. (and yes, the start-here-kde icons would need renaming finally) Cheers Friedrich
Re: liquidshell in kdereview
Hi Martin, Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > I'd like to announce an application I've implemented over the last few weeks > - liquidshell Congrats to the achievement. It surely feels good to run a workspace one has created one themselves :) While myself I will choose Plasma over liquidshell due to my needs and expectations of certain features, I can see that liquidshell would satisfy those persons who need or want just a simple hard-coded shell following a well-known UI design & concept, yet stay with the usual tools and apps from the KDE software world, ideally perfectly integrated with the workspace (think filemanager, terminal, text editor, etc). People like obviously yourself :) So those persons might be surely happy about you sharing your work with them. My hopes for liquidshell as another project under the KDE community umbrella: * improvements for shared middleware, perhaps even introducing some more where it makes sense to share between Plasma, liquidshell & others (pushing for more clear UI-core separation, which in theory is for good) libtm might be one such thing, the weather data provider system also calls for being shared code with Plasma (and e.g. the Marble weather plugin) * another testing ground for protocols & standards in development * make more obvious that "KDE" is about a community, not a certain software * give perhaps remaining trinity desktop developers and other Plasma-no-Qt-jay-fans a new center for their goals and as result also new contributors for the shared middleware, tools and apps (at least for their current QtWidgets UI variant ;) ) Re: gosh, yet another workspace In a perfect world everybody would join work on the one true golden workspace solution, reality is that there is no such one-workspace-which-fits-all. Not to forget the mythical person-month issue. And if people rather go and write their own software instead of joining existing projects, it should be the projects asking themselves why they have not been attractive enough in the first place. Telling people instead "you should not do X, but Y" is rather the opposite of what Free Software is about. Even when first saying "Your are free, but". I applaud you, Martin, for managing to solve your needs yourself and for sharing the results with the rest of the world, instead of keeping them for yourself. And as KDE community we can feel honored you trust us to be the best place for further development of your software, instead of going github or elsewhere. Re: liquidshell as name When I read liquidshell I first thought about something very dynamic, highly animated. So not sure "liquid" is the best term to use in the name. But then we all know naming is hard, good luck with it :) Cheers Friedrich
Re: liquidshell in kdereview
On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev wrote: > 2017-11-06 14:16 GMT+03:00 Kevin Funk : > > You're free to work on whatever you like to of course, but to me this > sounds > > like wasted effort. Your good incentives would be better spent with > joining up > > with others aiming for the same (LxQt for instance). > > Hi, > > I had a bad impression of LxQt because: > 1. it didn't work for me out of the box, > For many people kde applications don't work out of the box too. 2. it consists of many components, it's hard to figure out which of > them are optional, > Also true for kde applications. 3. it has poor infrastructure compared to KDE, e.g. their i18n server > hadn't been working for about a year. > I cant comment on that - but the project seems to be alive as there was a new release just last month with a lot of changes, also they use kf5 libraries where needed. > Thus liquidshell looks better to me than lxqt; joining an inferior > project is not a good idea. > please refrain from using words like 'inferior' for a project as it's not helpful. Currently the whole code for liquidshell is done for one person, and we (as in the KDE Sc) suffer for a lot of good projects and ideas that as soon as the original developers get tired the project stalls, like Macaw Movie, Spectacle, Baloo and quite a few others - so I'm really afraid of a one-man-project that's basically what other many projects already do. About liquidshell, I tried but it didn't even compile on my machine (some issue with Solid) > > -- > Alexander Potashev >
Re: liquidshell in kdereview
2017-11-06 14:16 GMT+03:00 Kevin Funk : > You're free to work on whatever you like to of course, but to me this sounds > like wasted effort. Your good incentives would be better spent with joining up > with others aiming for the same (LxQt for instance). Hi, I had a bad impression of LxQt because: 1. it didn't work for me out of the box, 2. it consists of many components, it's hard to figure out which of them are optional, 3. it has poor infrastructure compared to KDE, e.g. their i18n server hadn't been working for about a year. Thus liquidshell looks better to me than lxqt; joining an inferior project is not a good idea. -- Alexander Potashev
Re: liquidshell in kdereview
On Monday, 6 November 2017 10:03:05 CET Tomaz Canabrava wrote: > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller wrote: > > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > > > Hi all, > > > > > > > > I'd like to announce an application I've implemented over the last few > > > > weeks - liquidshell > > > > > > liquidshell is a replacement for plasmashell > > > > > > Hi Martin, > > > I'm a bit confused, who is liquidshell for? > > > > Whoever does not like plasmashell, for whatever reason. > > My reasons are mentioned in the README or the announcement mail. > > Free software is about choice, no ? > > It is, of course. Then, it's also about non-fragmentation, and you know, > human resources are spare. > I know it's your time and your project and I will never tell you what to > do, > but considering that there's lxqt which exists basically for the same > 'whatever reasons', why not help them instead of creating yet another > desktop shell? So much +1. I'm really sad to see more fragmentation in the DE space instead of finding people investing their time helping existing projects, even more so if there's one aiming for the same goal under the KDE umbrella. You're free to work on whatever you like to of course, but to me this sounds like wasted effort. Your good incentives would be better spent with joining up with others aiming for the same (LxQt for instance). Hate to be the party pooper here, but I'm just not sure this kind of fragmentation helps KDE in the long-term, where we really have a hard time finding contributors for the majority of our *existing* projects. Regards, Kevin > > Best regards/Schöne Grüße > > > > Martin > > A: Because it breaks the logical sequence of discussion > > Q: Why is top posting bad? > > > > () ascii ribbon campaign - against html e-mail > > /\- against proprietary attachments > > > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: liquidshell in kdereview
On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller wrote: > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > > Hi all, > > > > > > I'd like to announce an application I've implemented over the last few > weeks - liquidshell > > > > > > liquidshell is a replacement for plasmashell > > > > > > > > Hi Martin, > > I'm a bit confused, who is liquidshell for? > > Whoever does not like plasmashell, for whatever reason. > My reasons are mentioned in the README or the announcement mail. > Free software is about choice, no ? > It is, of course. Then, it's also about non-fragmentation, and you know, human resources are spare. I know it's your time and your project and I will never tell you what to do, but considering that there's lxqt which exists basically for the same 'whatever reasons', why not help them instead of creating yet another desktop shell? > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > > >
Re: liquidshell in kdereview
On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > Hi all, > > > > I'd like to announce an application I've implemented over the last few > > weeks - liquidshell > > > > liquidshell is a replacement for plasmashell > > > > Hi Martin, > I'm a bit confused, who is liquidshell for? Whoever does not like plasmashell, for whatever reason. My reasons are mentioned in the README or the announcement mail. Free software is about choice, no ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Sonntag, 5. November 2017 23:01:52 CET Alexander Neundorf wrote: > On 2017 M11 5, Sun 19:27:27 CET Martin Koller wrote: > > On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote: > > > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote: > > > > Hi all, > > > > > > ... > > > > > > > - Just one bottom DesktopPanel, containing: > > > I always put my panel to the right or left edge (intead at the bottom)... > > > > Then I fear liquidshell is simply not for you. > > ... I guess in doubt you wouldn't mind some patches ? of course patches are welcome, at least until they do not introduce a whole lot of troubles (e.g. I fear that the taskbar as it is right now is rather useless when running the panel vertically, except you make it ridiculously wide). I just can remember that I tried to fix panel widgets in KDE3 times(!) where there were troubles with the widgets trying to be useful even in vertical orientation. But let's see with what you come up ;-) -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > Hi all, > > I'd like to announce an application I've implemented over the last few weeks > - liquidshell > > liquidshell is a replacement for plasmashell > > It does not use QtQuick but instead relies on QtWidgets, > therefore no hardware graphics acceleration is needed. > > Main Features: > - Wallpaper per virtual desktop > - No animations, no CPU hogging, low Memory footprint > - Instant startup > - No use of activities (I never used nor needed them) > - QtWidgets based, therefore follows widget style from systemsettings > - Icons are used from your globally defined icon theme from systemsettings > - Colors are used from your globally defined color theme from systemsettings > - Can additionally be styled with css by passing the commandline option > -stylesheet filename.css > (see included example stylesheet.css) > - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual > Desktops, Bluetooth, Network > - Just one bottom DesktopPanel, containing: > StartMenu (allowing drag of entries into konqueror/dolphin to configure > QuickLaunch or AppMenu entries) > QuickLaunch (showing icons for .desktop files from a configurable folder) > AppMenu (showing .desktop files in a menu from a configurable folder, > defaults to users desktop folder) > Pager (for switching virtual desktops) > WindowList (Popup showing all open windows on all desktops) > TaskBar (showing windows on the current desktop, allowing drag of an entry > onto the Pager to move to a different desktop) > LockLogout > SysLoad widget including CPU, Memory, Swap and Network bars, live updated > tooltip > SysTray with integrated Network-, Notifications-, Device Notifier-, > Bluetooth-, Battery- display. > Display of StatusNotifier items from other applications (no legacy > embedded icons yet). > Notifications kept in a history list for some minutes, including > timestamp and text selectable per mouse > (very handy for copy/paste of TAC numbers from online banking received > via SMS and transferred to KDE >via kdeconnect) > Clock widget (with calendar popup, tooltip for selected cities) > - Desktop can contain applets (there's currently only a weather applet) > > The main motivation was to have a reliable desktop shell which does not hog > the CPU or RAM. > (CPU usage and stability were the things driving me mad with plasmashell) > It should be slick and have just the features I need in my daily > work. No need having all the bells and whistles anyone can think of. > Just have a plain, solid, fast workhorse. > > I think the final place should be extragear. > > Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory > are already in place > and ready to be installed. > > Screenshots: > light color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174650.png > dark color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174944.png > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > > Hi Martin, I'm a bit confused, who is liquidshell for? Aleix
Re: liquidshell in kdereview
Il giorno Sun, 05 Nov 2017 19:24:55 +0100 Martin Koller ha scritto: > > * Use QDBus instead of calling dbus-send command-line tool or > > xdg-screensaver > Because ? Personally, because I don't think that calling random executables from your program is a good idea. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B pgpjoVC8Ja7cB.pgp Description: Firma digitale OpenPGP
Re: liquidshell in kdereview
On 2017 M11 5, Sun 19:27:27 CET Martin Koller wrote: > On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote: > > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote: > > > Hi all, > > > > ... > > > > > - Just one bottom DesktopPanel, containing: > > I always put my panel to the right or left edge (intead at the bottom)... > > Then I fear liquidshell is simply not for you. ... I guess in doubt you wouldn't mind some patches ? Alex
Re: liquidshell in kdereview
On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote: > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote: > > Hi all, > ... > > - Just one bottom DesktopPanel, containing: > > I always put my panel to the right or left edge (intead at the bottom)... Then I fear liquidshell is simply not for you. > ... > > The main motivation was to have a reliable desktop shell which does not hog > > the CPU or RAM. (CPU usage and stability were the things driving me mad > > with plasmashell) It should be slick and have just the features I need in > > my daily > > work. No need having all the bells and whistles anyone can think of. > > Just have a plain, solid, fast workhorse. > > Not sure whether "liquid" is a good choice then, I don't really associate > "solid" with it ;-) I was thinking about "solidshell" but "Solid" has already a different meaning inside KDE ... -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
Hi, thanks for you review! On Samstag, 4. November 2017 19:41:27 CET Kai Uwe Broulik wrote: > Hi, > > AppMenu.cxx: > * You can use NoDotAndDotDot flag in entryInfoList() to already skip those I just want to skip ".." - but yes, I can use QDir::AllEntries | QDir::NoDotDot > * You seem to be using KFileItem and the url you generate just for > isDesktopFile(), you could use KDesktopFile::isDesktopFile(), also the > isDir() check could come before, a folder cannot be a desktop file That does not work. KDesktopFile::isDesktopFile() does not open the file but just checks the file extension. I do have desktop files without extension. The url is used for starting the desktop file (see the lambda function at the bottom of AppMenu::fill()) > Battery.cxx: > * It's using Solid/Power API that has never been released (and probably never > will be..) Interesting. On openSuse 42.2 it is included (released) in the solid-devel package. On what is "it was never released" based ? But I have no problem to use something else, if there is a way to know if the AC Power is plugged or not (and get a signal when it changes). What can I use instead ? > * you assume remainingTime() == -1 to be "when on AC", I'm not sure this > assumption holds I don't know either. I think this was based on try/error. Maybe with an alternative to Solid/Power I can change that. > * secsToHM looks not ideal form an i18n perspective Suggestion ? > CMakeLists.txt: > * No project name set fixed > ConfigureDesktopDialog.cxx: > * instead of QOverload or old syntax you can > static_cast &)>(&KUrlRequester::returnPressed) Thanks for the hint, but this is really ugly to write. I see no advantage in doing so. > ConfigureDesktopDialog.hxx: > * Reason for *returning* const &? You mean this ? const DesktopWidget::Wallpaper &getWallpaper() const { return wallpaper; } Of course. What else ? > desktop.cxx: > * Missing AA_UseHighDpiPixmaps attribute fixed > DesktopWidget.cxx: > * window type NET::Desktop should imply NET::KeepBelow ok, removed > * The list of applets is completely hardcoded and makes assumptions in the > class (for "Weather" create WeatherApplet) > instead of using some plugin/introspection mechanism Yes, by intention. I have currently no plans to have a plugin mechanism > LockLogout.cxx: > * Use QDBus instead of calling dbus-send command-line tool or xdg-screensaver Because ? > QuickLaunch.cxx: > * Similar issues as AppMenu.cxx filter now on QDir::Files > * Internet browser assumes kde.org is start page yes. And ? This is a default entry if the user did not configure anything. And I don't know how to run the "default web browser" than using KRun() with an http url ... > StartMenu.cxx: > * Similar issues as LockLogout.cxx you mean system() instead QDBus ? Do you think there might be distributions not shipping the dbus-send command ? If so, I should change that, else - who cares. > SysTray.cxx: > * The fill function is also awfully hardcoded hardcoded is the part for the features I supply. Why do you think this is awful ? > General (UI) observations: > * Qt scales it quite well for high-dpi, however the application doesn't > announce high dpi support leading to blurry icons, especially tray icons since I have no hardware to test that, I did not care. However I have now added the AA_UseHighDpiPixmaps attribute > * The CPU indicator in the panel cannot be disabled and is distracting What I want is a system which is usually idle - which is one reason why I implemented liquidshell in the first place. On my system, I normally don't see any CPU bar at all. And if I see one, I go and check who's the culprit. > * There's lots of I18N substitution errors all over the place > (I18N_ARGUMENT_MISSING) how do you see this ? I don't know what to look for or change. > * The "device notifier" lists *all* devices (not just removables) That should not happen, since the code filters only on removable devices. See DeviceList::addDevice(): // show only removable devices if ( device.is() && !device.as()->isRemovable() ) { //qDebug() << device.udi() << "not Removable"; return; } // show only removable devices if ( device.parent().is() && !device.parent().as()->isRemovable() ) { //qDebug() << device.parent().udi() << "parent() not Removable"; return; } so which devices do you get which should not appear ? Or do you know a better way to check for removables only ? > and isn't scrollable if there are lots of devices, I can easily add a QScrollArea like in the NotificationList, but I think you usually should not have that many removable devices which would justify this. Maybe it's the problem that there are devices shown which should not. Let's find out which ones. > network also doesn't seem scrollable yes, it isn't. But I also think you will not have that many entries shown. Am I wrong ? > * No battery applet, I don't understand. You'd like to have a battery de
Re: liquidshell in kdereview
On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote: > Hi all, ... > - Just one bottom DesktopPanel, containing: I always put my panel to the right or left edge (intead at the bottom)... ... > The main motivation was to have a reliable desktop shell which does not hog > the CPU or RAM. (CPU usage and stability were the things driving me mad > with plasmashell) It should be slick and have just the features I need in > my daily > work. No need having all the bells and whistles anyone can think of. > Just have a plain, solid, fast workhorse. Not sure whether "liquid" is a good choice then, I don't really associate "solid" with it ;-) Alex
Re: liquidshell in kdereview
Hi, AppMenu.cxx: * You can use NoDotAndDotDot flag in entryInfoList() to already skip those * You seem to be using KFileItem and the url you generate just for isDesktopFile(), you could use KDesktopFile::isDesktopFile(), also the isDir() check could come before, a folder cannot be a desktop file Battery.cxx: * It's using Solid/Power API that has never been released (and probably never will be..) * you assume remainingTime() == -1 to be "when on AC", I'm not sure this assumption holds * secsToHM looks not ideal form an i18n perspective CMakeLists.txt: * No project name set ConfigureDesktopDialog.cxx: * instead of QOverload or old syntax you can static_cast(&KUrlRequester::returnPressed) ConfigureDesktopDialog.hxx: * Reason for *returning* const &? desktop.cxx: * Missing AA_UseHighDpiPixmaps attribute DesktopWidget.cxx: * window type NET::Desktop should imply NET::KeepBelow * The list of applets is completely hardcoded and makes assumptions in the class (for "Weather" create WeatherApplet) instead of using some plugin/introspection mechanism LockLogout.cxx: * Use QDBus instead of calling dbus-send command-line tool or xdg-screensaver QuickLaunch.cxx: * Similar issues as AppMenu.cxx * Internet browser assumes kde.org is start page StartMenu.cxx: * Similar issues as LockLogout.cxx SysTray.cxx: * The fill function is also awfully hardcoded General (UI) observations: * Qt scales it quite well for high-dpi, however the application doesn't announce high dpi support leading to blurry icons, especially tray icons * The CPU indicator in the panel cannot be disabled and is distracting * There's lots of I18N substitution errors all over the place (I18N_ARGUMENT_MISSING) * The "device notifier" lists *all* devices (not just removables) and isn't scrollable if there are lots of devices, network also doesn't seem scrollable * No battery applet, icon just opens KCM * "Bluetooth is not operational", why show the icon then * Notifications doesnt handle multiple incoming ones well (just stacks dialogs ontop of each other) * Start button breaks Fitt's law (I cannot open it by janking the cursor into the lower-left corner) * No multi-screen support whatsoever * I like the background color selector combination of ComboBox and "custom" * Often uses QString instead of enums * Task Bar does not announce "iconified geometries" to KWin thus minimize animations go to the wrong place (centre of screen usually) * The coding style and naming practises do not follow "modern" KDE Frameworks guidelines Cheers Kai Uwe
Re: liquidshell in kdereview
On Samstag, 4. November 2017 02:35:27 CET Alexander Potashev wrote: > Hi, thanks for the good stuff. > > Tried to build it here against relatively old Qt version, failed at > first attempt and had to do some tweaks (see attachment). > > OS: gentoo > gcc 5.4.0 > Qt 5.7.1 > KF 5.37.0 thanks. I've fixed things now to compile with older Qt (5.6) and older compiler (g++ 4.8.5) -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
Hi, thanks for the good stuff. Tried to build it here against relatively old Qt version, failed at first attempt and had to do some tweaks (see attachment). OS: gentoo gcc 5.4.0 Qt 5.7.1 KF 5.37.0 2017-11-03 23:30 GMT+03:00 Martin Koller : > Hi all, > > I'd like to announce an application I've implemented over the last few weeks > - liquidshell > > liquidshell is a replacement for plasmashell > > It does not use QtQuick but instead relies on QtWidgets, > therefore no hardware graphics acceleration is needed. > > Main Features: > - Wallpaper per virtual desktop > - No animations, no CPU hogging, low Memory footprint > - Instant startup > - No use of activities (I never used nor needed them) > - QtWidgets based, therefore follows widget style from systemsettings > - Icons are used from your globally defined icon theme from systemsettings > - Colors are used from your globally defined color theme from systemsettings > - Can additionally be styled with css by passing the commandline option > -stylesheet filename.css > (see included example stylesheet.css) > - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual > Desktops, Bluetooth, Network > - Just one bottom DesktopPanel, containing: > StartMenu (allowing drag of entries into konqueror/dolphin to configure > QuickLaunch or AppMenu entries) > QuickLaunch (showing icons for .desktop files from a configurable folder) > AppMenu (showing .desktop files in a menu from a configurable folder, > defaults to users desktop folder) > Pager (for switching virtual desktops) > WindowList (Popup showing all open windows on all desktops) > TaskBar (showing windows on the current desktop, allowing drag of an entry > onto the Pager to move to a different desktop) > LockLogout > SysLoad widget including CPU, Memory, Swap and Network bars, live updated > tooltip > SysTray with integrated Network-, Notifications-, Device Notifier-, > Bluetooth-, Battery- display. > Display of StatusNotifier items from other applications (no legacy > embedded icons yet). > Notifications kept in a history list for some minutes, including > timestamp and text selectable per mouse > (very handy for copy/paste of TAC numbers from online banking received > via SMS and transferred to KDE >via kdeconnect) > Clock widget (with calendar popup, tooltip for selected cities) > - Desktop can contain applets (there's currently only a weather applet) > > The main motivation was to have a reliable desktop shell which does not hog > the CPU or RAM. > (CPU usage and stability were the things driving me mad with plasmashell) > It should be slick and have just the features I need in my daily > work. No need having all the bells and whistles anyone can think of. > Just have a plain, solid, fast workhorse. > > I think the final place should be extragear. > > Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory > are already in place > and ready to be installed. > > Screenshots: > light color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174650.png > dark color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174944.png > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > > -- Alexander Potashev diff --git a/Battery.cxx b/Battery.cxx index cc9b6fc..01dda67 100644 --- a/Battery.cxx +++ b/Battery.cxx @@ -22,7 +22,7 @@ #include #include -#include +//#include #include #include @@ -49,7 +49,7 @@ Battery::Battery(QWidget *parent) hide(); else { -connect(Solid::Power::self(), &Solid::Power::acPluggedChanged, this, &Battery::changed); +///connect(Solid::Power::self(), &Solid::Power::acPluggedChanged, this, &Battery::changed); connect(device.as(), &Solid::Battery::chargePercentChanged, this, &Battery::changed); connect(device.as(), &Solid::Battery::chargeStateChanged, this, &Battery::changed); connect(device.as(), &Solid::Battery::timeToFullChanged, this, &Battery::changed); diff --git a/CMakeLists.txt b/CMakeLists.txt index 7077710..1cabcfa 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -16,7 +16,7 @@ find_package(Qt5 5.7 CONFIG REQUIRED COMPONENTS find_package(KF5 REQUIRED COMPONENTS WindowSystem WidgetsAddons ConfigWidgets Config KIO IconThemes ItemViews Archive - Notifications I18n NetworkManagerQt Service Solid BluezQt KCMUtils Crash DBusAddons + Notifications I18n NetworkManagerQt Service Solid BluezQt KCMUtils Crash DBusAddons KDELibs4Support ) set(SOURCES @@ -95,6 +95,7 @@ target_link_libraries(${TARGET} KF5::DBusAddons KF5::ItemViews KF5::Archi