Re: [Development] A face for the Qt Project
> Dear community, > > The Qt Project is a huge effort from many people, and for the same > reason, it's quite interesting to (1) Learn how to contribute and be > part of it, and (2) Analyze the interactions of the many > Qt modules. > > For people new to the project, contributing to Qt might be challenging, > but I'm certain we all agree that being clear, and provide all the > information in one place is crucial to at least enable them to do > the first step. > > On the other hand, if you have been around for a while, > you know that Thiago's blog has a good set of statistics [1] > that helps a lot to get an overview of the current state of the project. > > With these two ideas in mind, it makes sense to use qt-project.org > as the face of the Qt Project, highlighting the two previous points > I described. > > I would like to ask the community, if we are in favor of using > the proposal from [2] as qt-project.org. > > The goal will be to have this repository under our open governance, > so anyone will be able to suggest changes, as we do in Qt. > > The idea will be not to duplicate content from https://qt.io, > but focus on aspects related to contributing to the project. I really like the idea and I think your implementation is very good at giving an overview of the community and how to get involved. So +1 from me :) ># About the implementation > > The page you can see on [2] was generated with Dash, > a Python module based on Plotly [3], and the data comes from the > meta qt5.git repository, including also the qt-creator and pyside-setup > ones. > > The text you see on the left-side cards, comes from local Markdown > files, so also it would be straightforward to edit them. > > I will upload the code if the community agrees to go forward, > so then we could be able to create a public repository to keep > this code. I didn't knew about Dash, this looks like a very nice python tool to work with. When you release the code, I could try to see if I could implement something similar for KDE. Cheers, -- Carl Schwan https://carlschwan.eu KDE developer and maintainer of the KDE websites > > Cheers > > > [1] https://www.macieira.org/blog/qt-stats/ > [2] https://qt-project-org.herokuapp.com > [3] https://dash.plotly.com/ > > -- > Dr. Cristián Maureira-Fredes > R&D Manager > > The Qt Company GmbH > Erich-Thilo-Str. 10 > D-12489 Berlin > > Geschäftsführer: Mika Pälsi, > Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Freenode's IRC
Le mercredi, mai 19, 2021 4:49 PM, Giuseppe D'Angelo via Development a écrit : > On 19/05/2021 16:37, Andy Nichols wrote: > > > Rather than just move to another IRC server, we should really take this as > > an opportunity to move to another chat service as the official Qt Project > > chat. IRC has a terrible user experience and is not at all accessible for > > people who haven't been using it for decades like many of us. It does us a > > huge disservice when trying to attracting new contributors to point to our > > IRC. There are lots of better options out there now (which I see some of > > you on already), so lets move on already. > > The mandatory question is always the same: which ones? > > Do they have goals, policies, end-user agreements that are compatible > with a free software project? Do they have strong privacy requirements? Etc. Matrix is a nice alternative. It's free software, with strong privacy requirements (E2EE encryption for private chat and rooms, only need a user id + password to register, ...). Also there is currently at least 7 clients written in Qt: Nheko, NeoChat, Spectral, Quatermion, Kazv, Mirage and Fluffychat (Ubuntu touch edition). Disclaimer: I'm a co-maintainer of one of the client listed above (NeoChat). Cheers, Carl > > Thanks, > > -- > > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Freenode's IRC
Le mercredi, mai 19, 2021 5:24 PM, Shawn Rutledge a écrit : > > On 2021 May 19, at 17:14, Carl Schwan wrote: > > > > Le mercredi, mai 19, 2021 4:49 PM, Giuseppe D'Angelo via Development > > a écrit : > > > > > On 19/05/2021 16:37, Andy Nichols wrote: > > > > > > > Rather than just move to another IRC server, we should really take this > > > > as an opportunity to move to another chat service as the official Qt > > > > Project chat. IRC has a terrible user experience and is not at all > > > > accessible for people who haven't been using it for decades like many > > > > of us. It does us a huge disservice when trying to attracting new > > > > contributors to point to our IRC. There are lots of better options out > > > > there now (which I see some of you on already), so lets move on already. > > > > > > The mandatory question is always the same: which ones? > > > > > > Do they have goals, policies, end-user agreements that are compatible > > > with a free software project? Do they have strong privacy requirements? > > > Etc. > > > > Matrix is a nice alternative. It's free software, with strong privacy > > requirements (E2EE encryption for private chat and rooms, only need a user > > id + password > > to register, ...). Also there is currently at least 7 clients written in Qt: > > Nheko, NeoChat, Spectral, Quatermion, Kazv, Mirage and Fluffychat (Ubuntu > > touch edition). > > > > Disclaimer: I'm a co-maintainer of one of the client listed above (NeoChat). > > But which server then? Should we run our own? What if the admins don’t want > to? Maybe we should just use the KDE infrastructure? Then I wonder if any > changes there are on the way. One of the advantages of Matrix is that it's federated so you can have a room called #qt-labs:kde.org on KDE matrix server and in case someday Qt wants it's own server, it is perfectly possible to add a new alias #qt-labls:qt.io to the existing room and use it as main alias without having to move the existing users to a new room. Note that it would probably be a good idea to ask first to the KDE matrix admin before using KDE matrix infra :) Cheers, Carl Schwan https://carlschwan.eu KDE Developer ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Freenode's IRC
Le jeudi, mai 20, 2021 2:18 PM, Giuseppe D'Angelo via Development a écrit : > Hi, > > On 20/05/2021 13:47, Alejandro Exojo wrote: > > > On Wed, May 19, 2021, at 8:16 PM, Giuseppe D'Angelo via Development wrote: > > > > > - there's no registration required; > > > - the $newthing has proven stability, staff, resources, etc., and won't > > > disappear in a few months/years; > > > > > > - ... > > > > > > then anything is fine. > > > All other things being equal, the simplest measure would be to simply > > > move over to Libera. (...) > > > > Can Libera already be considered so quickly? A fork of a software is not so > > easy > > as the "fork" of a service, isn't it? We don't know if they will disappear > > in a > > month, or if Freenode will be fixed by then. Or if another "fork" appears. > > Sure, that's a fair question. > > Personally, > > 1. I trust the staffing (coming from Freenode); > 2. I trust the organization being entirely under EU law (it's in > Sweden), with a strong privacy policy; > > 3. I trust it not disappearing tomorrow; most of the sponsored servers > are switching from Freenode to Libera, and many big projects are moving > there (e.g. Ubuntu just voted in favor. Of course none will move > overnight, just like Qt isn't moving overnight; decisions + > practicalities will take some time). > > > > Also, I don't understand how not having to register can be a requirement at > > all, > > given that one needs to register, sometimes multiple times, to use some of > > the > > other official channels. E.g. to participate in the mailing list I of course > > need to subscribe to it, and to get an email account at all I would either > > need > > to register with some provider or use a work email address (or self-host > > or...). > > Or self-host, indeed. But nothing apart from your email is needed, and > that email is NEVER used for any commercial or marketing or research > purpose. Which is the same requirement for the mailing lists. It might > not be the case for some 3rd party services. > > > If at all, not requiring registration makes me more concerned about spam, > > trolling, harassment, etc. > > Which you can easily ignore (see user mode +g, +R). None of this has > been a major problem on Freenode so far. > > > I have my own biases after going through many pains to have a modern-ish IRC > > experience (self hosting Quassel, using IRC bouncers, etc.). I hope that the > > current active community of people on IRC doesn't get alienated if something > > else is chosen, but I also hope that something with proper features is > > chosen so > > I can be back online on those communities, because my paste experience with > > IRC > > makes me not want to go there again unless really needed. > > FWIW, I'm now on other IM platforms, and all of Matrix, Telegram, > > Mattermost and > > even Discord seem to have acceptable IRC integration, and some open source > > projects treat both sides of the integration as official channels. People > > seem > > to be aware of it, and the friction between the two feature sets and > > "idioms" of > > the platform are more or less respected. So a middle ground is possible as > > well. > > Sure, but this doesn't bring an answer to the original question: > > - Is the Qt community OK at staying on Freenode? (Currently it has an > official presence! Although noone seems to know better, esp. who is > the primary contact for this presence. Looking at the channels > registrations, the founders are Thiago, ossi, tronical, JP-Nurmi, but > that doesn't necessarily match who is the point of contact.) > > - If no: does it wish to move to another IRC network -- to where? > - If no: does it want to drop its official IRC presence? Implication: > the #qt* channels namespace will be released, and so up for grabs by the > first person passing by and registering channels in there. > > Lacking some formal voting infrastructure, how do we take this vote? > I'd say, KISS: please reply to this email and express your preference. I believe the best course of action would be to wait a bit until KDE moves its freenode presence to libera (should happen soon). And then Qt can move its freenode channels to libera and add Matrix bridging to the new channels with the KDE-Matrix instance. People who prefer IRC will still be able to use IRC, people who would like to use a more modern chat pro
Re: [Development] Mirror IRC channels on KDE's Matrix Instance
Le mercredi 14 juillet 2021 à 11:58 PM, Aleix Pol a écrit : > On Tue, Jul 13, 2021 at 12:30 PM Vladimir Minenko> vladimir.mine...@qt.io wrote: > > > I also use Element (on MacOS) since the Qt CS times. Here are some hints > > from my experience. For the Qt CS, I created an account on matrix.org and > > added it to Element. This is a separate account, not your KDE account. > > Chat channels are called “Rooms” in Element. Searching for Rooms is under > > Rooms -> “+” -> "Explore public rooms”, but the search doesn’t work so well > > or the indexing is not ready for the new mirrored IRC channels yet. I tried > > to search for “qt”, and only the one for Qt Created shows up. > > I added channels directly by copy-n-paste from the list in the Cristians’s > > email into the"Explore rooms” field showing up under "Explore public rooms” > > , e.g. #qt:kde.org . It cannot be found, but you can just hit the “join” > > button and you are done. > > I hope this helps! > > PS. As a yet another web app, Element eats another 700MB RAM, plus 1.4GB > > RAM for its “renderer" on my mac… 2GB per a web app?… Wow… > > Hi Vladimir, > Note that you can use Neochat: > https://apps.kde.org/neochat/ > > It's what I've been using for a while, like many of us in KDE, > although not on mac. We don't have official mac builds yet but there's > nightly builds. > > https://binary-factory.kde.org/view/MacOS/job/NeoChat_Nightly_macos/ > It's a Qt application that you can hack, it sure won't take 2GiB. (and > if it did, I'm sure some people here know how to help ;)). Hi, NeoChat does work on mac but more help on it would be welcome :) The NeoChat matrix channel can be found here: #neochat:kde.org :) Also if NeoChat is not to your liking https://matrix.org/clients/ list a few more native clients. 6 of them are written with Qt (Nheko is the most advanced and has working encryption and video chat) and there is also a native mac client (no idea how good it is) and fluffychat written in Flutter. I hope it helps. Cheers, Carl > > Cheers! > Aleix > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtWidgets Item / Model / View: tree model examples
On Tuesday, 21 November 2023 16:31:02 GMT+1 Laszlo Papp wrote: > Hi, > > ... > > Long time ago, I based my projects on these examples, inventing (copying > and pasting) these tree items. > > I wonder whether these examples could instead propagate the use of: > > 1. QTreeWidgetItem? > 2. QStandardItem? > > It seems that e.g. the QTreeWidgetItem is nearly the same as the Tree Item > invented in those examples. So, why reinvent? > > Do you think that the tree item still has a good use case to exist in those > examples? > > If yes, what is it? > > If not, could we start propagating QTreeWidgetItem or QStandardItem in > those examples instead to avoid reinventing? I also do that quite often for static tree models which is the reason why I recently ported the examples to use std::unique_ptr for memory management as it was one of the main modification I did after copying the example. The other two modifications I always do is to change the type contained in the TreeItem from QVariantMap to something else (struct or list of arguments) and change the data and roleNames method accordingly. See for example https://invent.kde.org/graphics/arianna/-/blob/master/src/ tableofcontentmodel.cpp?ref_type=heads#L9 I also did wonder if it would make sense to have this as a standalone component provided by Qt (ideally as a templated class as I'm not a big fan of the QVariant approach of QStandardItem), but I don't think it is suitable for more complex use cases than the very basic tree. But the example is quite helpful to understand how to build a more complex tree model and it can also be used as a base. A tree model (and a list model) are used to abstract the underlying data without having to convert the data beforhand in another data structure (e.g QStandardItem) which I think is quite powerful and we should encourage developers to make use of that. Cheers, Carl > > Thank you in advance. > > Kind regards, > László -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
