Re: Idea Submission: Does anyone please have con-args?
> Are there already projects aiming towards similar objectives? Or have there > been in the past? Yes, there are many if you consider euro as a big gov. From my experience, there are several made-in-china (similar to the "Self-sovereign identity") systems for past 20 years, and most of them failed. Wikipedia also have an incomplete page of state-sponsored-Linux-distros. Most of them wasted a large chunk of resources to craft just another set of default packages/wallpapers/theme/infra. I think region-based distro is anti-pattern of free software. If open source is about freedom, region-based distro is simply adding restrictions (Why limit the target users based on geography location?). It feels like NIH [1] but in large scale. A common name plus a distro is probably an inspirational symbol, but I think it might be better to spend more resources on _actual improvements_ of the software, such as funding software projects that are actually needed to get the jobs done, enhancing LibreOffice, translations for rare languages, tools to ease deployments for gov/school, and develop new technology for open source systems. Image KDE get fully funded programmers to improve the software that are required by euroOS, rather than a team of distro release engineers tweaking software packages. What is really needed is a "euroOS project", rather than yet another region-based "euroOS distro". A project will provide sustainable funding/resources for software projects that solve real problems for euro's gov/school/individuals. (If this actually happened, in the future, someone will use software with acknowledgment that it was produced/funded by the eurOS Project). Technical issues are less hard than political/economical ones. Other thoughts: * München switch to linux many years ago, but seems to have many struggling and tried to move back to windows. Not sure the situation now. * IIRC, the ScientificLinux was also funded by several euro-based organizations (mainly CERN I think). * The recent RockyLinux can be used to estimate how much resources are practically needed to duplicate everything, plus some branding. [0] https://en.wikipedia.org/wiki/Category:State-sponsored_Linux_distributions [1] https://en.wikipedia.org/wiki/Not_invented_here slbtty On Mon, May 17, 2021 at 5:10 AM Dominik Kummer wrote: > > Hi folks! > > I recently submited an ideas on > https://community.kde.org/SoK/Ideas/2021#eurOS%3A_Standard_European_Operating_System > based on personal conclusions studying several citizen > contributions/discussions on futureu.europa.eu. > > Do you see any realistic perspectives on this? > Does it even make sense, or would you consider it to centralized tailored? > Are there already projects aiming towards similar objectives? Or have there > been in the past? > Whats you opinion on SSI in general? > > Thank you so much for any further contra arguments and/or redirections!! > > Kind regards, Yours > > Dominik > > >
Re: Unified internal communications channel
Why not push this more radically by shutting down mailing lists? This story keeps repeating itself. * Long time project primarily used mailing list in the past -> New people come, but they bring a new communication channel -> Split, the community have to choose one -> Choose the new communication because the new communication channel causes the split So, deprecating the mailing list and setting up a new discourse section for developers would be the first step. The next step is linking a short tutorial of Discourse's mailing list mode for email lovers. I find Python's discourse is superior. Normal users can ask questions, while core developers can discuss proposals. They have "Committers" and "core dev" sections, which are supposed to be low volume. Only officially recognized developers can use "Committers" section. https://discuss.python.org Other similar things Julia internals https://discourse.julialang.org/c/dev/5 Rust internals https://internals.rust-lang.org On Thu, Dec 7, 2023 at 10:16 AM Nate Graham wrote: > > Hello everyone, > > There have been a couple instances of drama this week caused by > decisions being made without some of the relevant stakeholders knowing > about them. In all cases, the decisions were announced, but either not > announced in the places where all the stakeholders saw it, or not all > stakeholders were able to notice the announcement in a place where they > do generally pay attention. > > It makes me think that maybe the KDE development community has grown so > large that we can't reasonably expect everyone to be paying attention to > everything, or for everyone with something to announce to know exactly > where the people who need to know it expect to find those messages. > > So perhaps this could be addressed at the source by creating a single > unified "internal announcements" place that everyone can pay attention > to without fear of being spammed with too many messages. In theory the > kde-devel mailing list is one such place, but it's got more than just > announcements, and also mailing lists aren't very accessible for a lot > of newer contributors who didn't grow up with them. > > What I'm proposing is some kind of place that *only* has internal > announcements and is very log signal-to-noise such that we can > fearlessly recommend that *everybody* subscribe to it. In addition, > ideally those who want to subscribe via mailing list could do so, but > its content would automatically appear in other places too, such as > discuss.kde.org and an invent.kde.org project. That way people can > subscribe by whatever means is most comfortable to them. > > Thoughts? > > Nate
Re: KGeoTag's main window position is not restored
It is not possible anymore in Wayland because window coordinates cannot be set. On Sun, May 26, 2024 at 11:37 AM Tobias Leupold wrote: > > Hi all! > > I'm a bit lost with this one. Maybe someone with more insight in KXmlGuiWindow > could give me a hand about this? Most probably, this is PEBCAK ;-) > > Currently, KgeoTag's main window position is not restored when closing it and > opening it again. The dock arrangement is restored, and also the window size > -- but the window always appears always in the middle of the screen. > > Initially, I used a QMainWindow and stored the windowState() manually, to > restore it in the main window's ctor. Later on, I ported the main window to > KXmlGui, keeping the manual restore. > > I now noticed that KMainWindow also stores the window state on closing, > although I never called setAutoSaveSettings(), along with some position > parameters that are stored differently from what QWidget::saveGeometry() would > yield. > > I now created the "xmlgui" branch, where the duplicate saving of the window > state is removed, and setAutoSaveSettings() is called. > > However, neither with the master branch (without setAutoSaveSettings()), nor > with the xmlgui branch (with setAutoSaveSettings(), most probably more the way > this is intended to be used), the window's position is restored -- the window > always appears in the middle of the screen. > > At this point, I'm completely out of ideas why this doesn't work and how I can > fix it. has anybody an idea?! > > Thanks a lot for all hints! > > Cheers, Tobias > >
