On 2025-05-09, Sune Vuorela wrote:
> It looks like it is built on a range or a collection/container of
> tuples or something like that
I just digged in my personal archives and found from 2016
| class TemplatedMagicModel : public QAbstractTableModel
I'm definitely not saying
On 2025-05-09, Volker Hilsheimer via Development
wrote:
> It’s not abstract, but it’s also not specific.
It looks like it is built on a range or a collection/container of
tuples or something like that
QRangeBasedItemModel ?
QTupleCollectionItemModel ?
QContainerItemModel ?
I'm a bit with Guis
On 2025-03-24, Ulf Hermann via Development wrote:
> Q_DEFAULT_PROPERTY(int, value)
>
> That would expand to:
The amount of custom macros like that I have removed is quite big.
Programers are lazy. They will also use that macro for readonly
properties, and constant properties.
/Sune
--
Develo
On 2025-01-16, Marc Mutz via Development wrote:
> Can we, please, settle this by strengthening the wording of
> https://wiki.qt.io/API_Design_Principles#Enums_in_classes to something
> that requires scoped enums?
>
> I believe everyone agrees that there are _technical_ reasons to prefer
> scope
On 2024-12-02, Alexandru Croitor via Development
wrote:
> Yocto 4.0 has it, debian 11 and 12 have it, ubuntu 22 and 24 have it, RHEL 8
> and 9 have it, so I don't think this should be too controversial.
With my debian and user hat on, I don't think caring for debian old
stable (currently Debian
On 2024-11-14, Joerg Bornemann via Development
wrote:
> On 11/14/24 09:14, Sune Vuorela wrote:
>
>>> Or is it more specific that you think that the backports-provided cmake
>>> will not be stable enough for building software?
>>>
>>> CMake is generally
On 2024-11-13, Alexandru Croitor via Development
wrote:
> Do you consider it unreasonable due to backports being 'backports', so not
> 'stable', thus you are completely against installing any software from there?
Yes. Also I need other projects I work at to not pull in a too new CMake
by accid
On 2024-11-13, Alexandru Croitor via Development
wrote:
> Which debian stable version are you using?
Debian stable is debian 12. It ships with 3.25.
> Is it unreasonable to ask to install cmake from one of those official repos?
Backports are not part of stable, so yes, I would consider that is
On 2024-11-13, Alexandru Croitor via Development
wrote:
> Hi,
>
> We'd like to bump the minimum required CMake version for building and using
> Qt to CMake 3.26.
> If you have some feedback on why that might be a problem, please reach out.
While I don't have that many current contributions to
On 2023-12-15, Elias Steurer via Development wrote:
> No, I still need all the get/set/notify functions to change/get the
> variables from the outside. There is currently no way to do that, or am
> I missing something? Something like this
> https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/
On 2023-05-04, Marc Mutz via Development wrote:
> So, enum-backed APIs taking int will have to be ported to take the enum
> instead. On the plus side, you get type-richer and safer APIs.
How would you do the extensions (e.g. user roles or user events)
if you convert to enums ?
/Sune
--
Devel
On 2023-05-04, Marc Mutz via Development wrote:
> that keeps unported code running. The main issue isn't the scoping, the
> main issue will be the missing implicit conversion to underlying_type.
In few cases the implicit conversion to underlying_type is kind of important.
Especially in the case
On 2023-05-03, Thiago Macieira wrote:
> 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian
> will
> probably release its next stable before Qt 6.7, though whether it'll still
> upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum
Debian 12 "Bookw
On 2020-11-17, Kai Köhne wrote:
> Why should the packages in the online installer change? They are hardly ever
> installed into some general directory.
To have documentation be "Run this command `foo`". not "If you are
running linux or mac and have gotten your Qt the normal way thru your
package
On 2020-11-02, Lars Knoll wrote:
> I honestly don't think renaming all our binaries is an option, certainly not
> that late in the process. We’ve had Qt 4 and Qt 5 co-installed for a long
> time as well and while that might not be perfect it was working.
>
> And qtchooser has been working nicely
On 2019-05-23, Lars Knoll wrote:
I'm a bit late to this game, but ...
> I don’t see why you’d want to remove the switch for Qt 6.
> It would be a porting help for application developers.
Application developers will not build their own Qt, but rely on the
QList with the switch their Qt and Qt-us
On 2019-01-25, Lars Knoll wrote:
> * I think it makes the life of casual/new contributors easier. Simply always
> develop and push against the development branch. The more experienced
> reviewer can then easily decide that the fix should be cherry-picked into a
> stable branch.
I'm mostly a
On 2018-10-28, Thiago Macieira wrote:
> But if it isn't spam, what gives the list moderator the right to intervene in
> something that he/she believes is abusive behaviour? Same thing about IRC: we
> do have one annoying person who does come along every now and then, but most
> of his messages
On 2018-09-12, Gatis Paeglis wrote:
> +1 for deprecating qtx11extras as well and moving the code closer to actual
> plugin. It is frustrating to have all that boilerplate code for 1 header file
> - qx11info_x11.h
I think it makes sense to have qtx11extras. A stable api and abi that
X11 users ca
On 2018-03-19, Denis Shienkov wrote:
> As I can see recently, is is not a good tendence in Qt... Many peoples
> leaves from Qt.. What happens? Or I'm mistake? :)
Let's do some math.
There is around 160 maintainer positions in Qt (a quick count of on
the maintainers wiki page)
Many maintainer
On 2017-03-08, Jake Petroules wrote:
> I'm working on the qbs bootstrapping. The requirements will be: a C++11 com=
> piler. End of requirements. Seriously. Not even bash, if you don't mind typ=
> ing a couple commands manually.
I don't mind a bat script, a bash script or whatever is needed, but
On 2017-03-07, Lars Knoll wrote:
> This also makes qbs a natural choice to also use for Qt itself, and I belie=
> ve all the people that have worked and maintained Qt's build system over th=
> e last few years are supporting this. Of course this requires that we can s=
> how that qbs can be used t
On 2016-12-17, Soroush Rabiei wrote:
> it's wrong to add such implementation to QDate. My view of QDate is this:
> QDate represents a day in time. So it only needs to know what day it is
> (how many days are to the day 0).
And it is exactly things like that that would prevent partial date
support
On 2016-12-15, Soroush Rabiei wrote:
> 2.History
>
Hi
I would welcome more calendar systems. Personally I hope for french
revolutionary calendar. Because it is funny.
I think you need to touch quite some of the 'inner bits' of date / time,
and while you are there, I'd love if the design could
On 2016-09-23, André Pönitz wrote:
> That gives already "surprising" behaviour if fed with QChar('a') and
> QString("a") in a row.
>
> And it is "surprising" to a degree that I'd call it buggy.
Then try feeding it boolean's and strings.
QQmlPropertyMap map;
map.insert(QLatin1String("key1"),true)
On 2016-09-09, Edward Welbourne wrote:
> https://codereview.qt-project.org/170634 -- qtbase
Added some comments. Though didn't detailed read all template magic.
One enum have reordered some members. This is likely an issue.
> https://codereview.qt-project.org/170635 -- qtdeclarative
Kind of loo
On 2016-09-05, Giuseppe D'Angelo wrote:
>> * C++ ABI
>> * libstdc++ still breaking compatibility in std::function
>> * not now, revisit in a year or two
>
> There hasn't been time to discuss this at QtCon, but I'd say we should
> not spend another year before revisiting this at the next Qt
On 2016-09-05, Andrew Knight wrote:
> tl;dr: Lots of discussion on the merits of which build system (CMake,
> Qbs) should replace qmake in building Qt; lots of supporters of CMake
> but no volunteers to do the work, many reasons to use Qbs as well. Some
I do think that there is volunteers to g
On 2016-08-24, Thiago Macieira wrote:
> And its address is copyable, so if we replaced the pointer with something,
> we'd have to use something copyable and non-owning.
class QObjectHandle {
public:
QObjectHandle(QObject* obj) : m_obj(obj) { }
operator QObject* () const ( retur
On 2016-08-12, Fredrik de Vibe wrote:
> We have recently been working on an implementation of OAuth (1+2), and
> this is now approaching a state in which it can be distributed as a tech
> preview. For this we'll need a new public repository.
there is a handful of external projects doing oauth w
On 2016-07-14, Thomas Senyk wrote:
I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.
> should "fix" it? .. but I still see 100% cpu and same memory consumption?
I debugged some time ago a case of a unresponsive application (for 3
On 2016-07-11, Allan Sandfeld Jensen wrote:
> On Monday 11 July 2016, Benjamin TERRIER wrote:
>> QImage::detach() is not public API.
>> However QPixmap::detach() is, so why QImage::detach() couldn't be made
>> public too?
>>
> It probably should be. It is a lot more sensible to use than copy(rect
On 2016-07-01, Thiago Macieira wrote:
> confusing because the next line has "isEmpty". When I read this code, I had
> to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
Hah. I found some code in a large project
On 2016-06-14, Konstantin Tokarev wrote:
> QScopedPointer lacks custom deleters which make it unusable for the purpose
> of managing Windows HANDLEs (see original post).
You can pass your own classes as handlers, provided that they have a
public static function void cleanup(T *pointer).
- from
On 2016-04-05, Thiago Macieira wrote:
> If it is, can someone try a regular toolchain for that platform with Qt 5.6
> and report whether QtCore links? I'd like a second opinion with a different
> toolchain than the reporter.
looks like 5.6 is built in debian/experimental on armel (v4t/v5)
buil
On 2016-03-29, René J.V Bertin wrote:
> Can someone point me in the right direction, maybe to a tutorial of sorts
> that outlines how to do several code reviews from a single working copy?
>
> I'm not exactly familiar with using branches; I just tried to create one,
> apply a patch, commit it a
>
> TBUG-51676 seems to be p2 and so on cannot block the release. It also have
> been open a while without anyone indicating it should be fixed before
> releasing so I wouldn't block the release because of this at this point
> anymore. I think adding this in known issues page
> (https://wiki.qt
On 2016-03-01, Milian Wolff wrote:
> b) Apparently there are never any debug symbols shipped for the release build
> fo Qt. Having debug symbols even for a release build is crucial for a good
> profiling experience. Could we maybe get release builds in the future with -
> force-debug-info to imp
On 2016-02-11, Thiago Macieira wrote:
>> There are several remaining issues in the report. So I have some questions:
>>
>> - Is class QPlatformScreen private and all related changes should be removed
>> from the report?
>> (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/8f965
On 2016-02-02, Liang Qi wrote:
> Above three are not applications, they must be input context plugin of Qt,
> just like ibus in
> https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputconte=
> xts/ibus
> . Normally every input method software could/should have one of this kind
> of
On 2016-01-22, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote:
>> Speaking of workarounds :
>> I have to use this ugly hack that depends on otherwise inaccessible c=
> ode to
>> update QPrintPreviewDialog
>>=20
>> //dia is a QPrintPreviewDia
On 2015-09-17, Frederik Gladhorn wrote:
> --- a/src/corelib/tools/qbytearray.h
> +++ b/src/corelib/tools/qbytearray.h
> @@ -43,6 +43,7 @@
> #include
>=20
> #include
> +#include
>=20
> #ifdef truncate
> #error qbytearray.h must be included before any header file that defin=
> es truncate
> @
On 2015-07-17, Takao Fujiwara wrote:
> Right. ibus-qt already has the ibus module for qt4 so this request is for qt5.
> I'd think it's easy to move libibusplatforminputcontextplugin.so from qtbase
> to ibus-qt.
Part of me would like to have as many things that uses QPA headers to
stay inside Qt
On 2015-07-12, Andre Somers wrote:
> become easier to make the transition in user code? Then, if Qt itself
> changes its API in Qt 6 to use QVector instead of QList, the users' code
> will just work :-)
In Qt6, QList can be fixed. The issue is what to do until then.
/Sune
On 2015-07-05, Massimo Callegari wrote:
> Update #2 (sorry for spamming)
>
> I patched qgstreamervideowindow.cpp and qgstreamervideowidget.cpp to support
> the linuxfb platform.
> It kinda works !!
>
> Screenshot here: http://pasteboard.co/1JlYRT9l.jpg
>
> Videos can be played hardware decoded wi
On 2015-06-26, Olivier Goffart wrote:
> Can we have function that takes or return std::function, std::tuple,
> std::unique_ptr, std::vector?
While I can see the advantage of std::function, I'm not sure why we
would use the remaining ones in API ?
Thiago already mentioned that he didn't like std
On 2015-06-18, Koehne Kai wrote:
>> 1. Each Qt Module "Qt Foo" (name used in docs), with soname
>>QtFoo, only exports symbols in namespace QtFoo,
>>potentially with nested inline namespace V.
>
> This has the advantage of being a very simple, mechanical rule. But it's also
> very burdensom
On 2015-03-01, Samuel Gaist wrote:
> Hi,
>
> Since Stephen Kelly ended his work at KDAB, he also got out of gerrit/jira so
> it seems that there's no official maintainer for the Item View module, unless
> he's there with a new account I missed ?
I spotted him some time ago in gerrit as 'ske'
On 2015-02-28, Gunnar Roth wrote:
>
> UC writes BSD Unix files not about general source code.
I don't think that UC has published anything else but BSD Unix.
> And why does gnu,org not update their website,but till insists on
> incompatibility with the GNU GPL?
In the general case, the incom
> Well https://www.gnu.org/licenses/license-list.en.html says
> Original BSD license (#OriginalBSD)
> This license is also sometimes called the “4-clause BSD license”.
>
> This is a lax, permissive non-copyleft free software license with a serious
> flaw: the “obnoxious BSD advertising clause”. Th
On 2015-02-16, Rex Dieter wrote:
>>From my reading of
> http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/
>
> It may depend on the value of _GLIBCXX_USE_CXX11_ABI macro, but I admittedly
> don't yet fully grasp the implications of it being set either way.
Yes. it does depend on lots of
On 2015-02-16, Rex Dieter wrote:
> * QT_BUILD_KEY handling
>
> Similar to webkit above, the configure bits about QT_BUILD_KEY only handles
> up to gcc-4.x.
>
> For fedora 22, our gcc5 builds are done in a way that is (supposedly) ABI
> compatible to gcc4, so I'm currently using:
> http://pkgs.fe
On 2015-02-15, Alejandro Exojo wrote:
> People might rely on the function in proprietary applications in ways that
> are
> impossible to predict.
Every time we fix a bug, we might introduce regressions for people
relying on the bugs. That's not a reason for not fixing a bug.
/Sune
___
Hi
After a couple of patches [1], most submitted to gerrit, my current qtbase dev
build on linux is bitwise reproducible. This is the first step to let
end users check that the binaries they recieve actually matches the
sources they recieve.
The first simple steps is 1) ensure __DATE__, __TIME__
On 2015-01-19, Oswald Buddenhagen wrote:
> your problem is a self-made one: the attempt to co-install major
> versions of everything. this is a linux distro specific problem, and
> demanding x-platform upstreams to accept trade-offs to adjust to it is
> *unreasonable*.
I do wonder about one thing
On 2014-11-28, Simon Hausmann wrote:
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have
> to
> write:
I have a lot of code in the wild using classes and Q_GADGET.
Having Q_GADGET not change
On 2014-09-24, Yam Marcovic wrote:
> However, I will say I don't want to force people to give their sources away
> if they use it.
>
> So a license along the lines of 'this license is here for formal purposes;
> but feel free to do anything you want with this,' is good enough as far as
> I'm conce
On 2014-08-26, Allan Sandfeld Jensen wrote:
> Well. That would the safe way, and we should keep that in mind for Qt6, but I
> believe with symbol versioning it can be done without breaking ABI, assuming
> it works as advertised. The libraries would export all symbols as both their
> normal form
On 2014-08-20, Thorvaldur Jochumsson wrote:
> Hi I am currently designing multimedia support for my application. I am
> wondering which approach to take. Should I make use of the phonon library
> or make use of the multimedia support provided in the Qt multimedia
> library? We are currently making
On 2014-07-03, Milian Wolff wrote:
> I imagine, it could work by create just a normal library but not install and
> public headers, only private ones. That should be OK then, or what do you
> think?
We have too many private headers already. We should work on getting rid
of them, not to create n
On 2014-06-30, Olivier Goffart wrote:
> We need also to identify private APIs that could be polished and made public.
The first step here is, from your friendly packagers POV, the QPA
API's.
One thing is that we need to be very careful with combining the
components released by the Qt project, an
On 2014-06-30, Olivier Goffart wrote:
> Totally off topic: I think using private header should be tried to be
> avoided.
> In the past, we used private header inside Qt because Qt was not split that
> much. But one of the goal of modularisation was to allow independent release
> of different
On 2014-05-10, Thiago Macieira wrote:
> How do you make 5.3.0-rc1 compare less than 5.3.0?
we call them 5.3.0~rc1.
/Sune
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On 2014-05-09, Keith Gardner wrote:
>2. What semantics should be used for version comparisons? Numerical
>segments are more clearly defined but when introducing a non-null suffix,
>many different methods are being proposed.
> 3. Are there any other versioning semantics that shou
On 2014-04-23, Andrey Ponomarenko wrote:
> I've created the ABI compatibility report between 5.2.1 and 5.3.0-beta
> versions:
> http://upstream-tracker.org/compat_reports/qt/5.2.1_to_5.3.0-beta/abi_compat_report.html
>
> Hope it may be helpful to analyse changes in headers.
that abi tool is btw
On 2014-04-22, Thiago Macieira wrote:
> --- a/src/widgets/widgets/qlcdnumber.h
> +++ b/src/widgets/widgets/qlcdnumber.h
> @@ -43,7 +43,6 @@
> #define QLCDNUMBER_H
>
> #include
> -#include
>
> QT_BEGIN_NAMESPACE
>
I guess this is theoretically a SiC change, but one that could also be
ig
On 2014-04-22, Thiago Macieira wrote:
> --- a/src/serialport/qserialport.h
> +++ b/src/serialport/qserialport.h
> @@ -64,11 +64,11 @@ class Q_SERIALPORT_EXPORT QSerialPort : public QIODevice
> Q_PROPERTY(FlowControl flowControl READ flowControl WRITE setFlowControl
> NOTIFY flowControlChange
On 2014-04-22, Thiago Macieira wrote:
> --- a/src/network/ssl/qsslconfiguration.h
> +++ b/src/network/ssl/qsslconfiguration.h
> @@ -131,6 +132,21 @@ public:
> +static const char NextProtocolSpdy3_0[];
> +static const char NextProtocolHttp1_1[];
These static const char[] kind of triggers m
On 2014-04-22, Thiago Macieira wrote:
> -QGeoCodingManagerEngine(const QMap ¶meters,
> QObject *parent = 0);
> +QGeoCodingManagerEngine(const QVariantMap ¶meters, QObject *parent =
> 0);
Given it is just changes to typedefs, it should be okay. There are quite
many of those across this d
On 2014-01-20, Thiago Macieira wrote:
> On segunda-feira, 20 de janeiro de 2014 21:30:37, Sune Vuorela wrote:
>> On 2014-01-20, Thiago Macieira wrote:
>> > Windows
>> > ---
>>
>> [QTBUG-35500] Fix printing on Windows. QPrinter now reports proper page
&
On 2014-01-20, Thiago Macieira wrote:
> Windows
> ---
[QTBUG-35500] Fix printing on Windows. QPrinter now reports proper page
sizes for system printers.
(I would like another sentence about the actual implications. For me, it
was that my custom printing code went from 'completely broken' to
On 2014-01-13, David Faure wrote:
> Mounting can still be done with `mount`, no?
Only in rare cases. Normally on linux from a user app you would call out
to udisks, who would connect to polkit and have polkit maybe query you
and other magic.
> Notifications mean listening to dbus signals though,
On 2013-12-18, Ziller Eike wrote:
>
> On Dec 18, 2013, at 5:35 PM, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
>> Hi! I would like to now if it's acceptable for the project to have 3rd party
>> code with the following statement in 3rd party sources:
>>
>> "The Software shall be used for Goo
On 2013-10-21, Thiago Macieira wrote:
> Anyway, my suggestion thus:
> - QtSerialPort: statically link to libudev
btw, does anyone know how close the libudev version should match the
udev-daemon version? are there any library/daemon protocol stability
guarantees?
What happens if there is a mism
On 2013-10-21, Thiago Macieira wrote:
> But what distributions are those that don't have libudev.so.0?
Most modern ones I think.
>
> http://git.kernel.org/cgit/linux/hotplug/udev.git/tree/Makefile.am
Note that udev in general is built from systemd source tree, even for
distributions that don't
On 2013-09-09, Giuseppe D'Angelo wrote:
> Indeed, but how about starting with an addon and then moving the
> classes inside QtCore? We can freely break API/ABI in addons -- when
> things get stabilized, we start including them in QTCore/QtNetwork...
I'm not sure what a addon containing 1 small cl
On 2013-01-28, Thiago Macieira wrote:
> I'd rather skip that step and simply go to -Werror. Lars proposed that we
> experiment with it a little and see how far it goes before turning it on.
>
> The good thing about -Werror is that the failure comes fast.
The bad thing about -Werror is that it tr
On 2013-01-28, Knoll Lars wrote:
>>> 1) always with -developer-build
>>> 2) on by default on -developer-build, but the CI disables it
>>> 3) completely optional, CI enables it
>>> 4) completely optional, not enabled by the CI
> I'd favor (2) for now, and move over to (1) once we gained a little
On 2013-01-22, Thiago Macieira wrote:
> Sune, especially for you: will you try and patch Qt to change the sonam=
> e if we=20
> don't do it?
Sorry for answering a bit late.
Given that we haven't yet formally published Qt5, no.
if we had, then it would be a definately maybe depending on a insan
On 2012-12-13, Jenssen Tim wrote:
>> "I would prefer that you didn't submit this"
>>
>> reads to my brain much like "go f*k yourself" without the raw words.
>>
>> I get all the idea of the automating thing and all, and that machines have no
>> emotion, but, if I don't miss something obvious (this
On 2012-12-09, Sune Vuorela wrote:
> On 2012-12-09, Marc Mutz wrote:
>> 3. new features and bug-fixes that require new strings or BiC changes should
>>be submitted to 'dev' directly.
>
> binary incompatible changes should not be submitted anywhere except fo
On 2012-12-09, Marc Mutz wrote:
> 3. new features and bug-fixes that require new strings or BiC changes should
>be submitted to 'dev' directly.
binary incompatible changes should not be submitted anywhere except for
Qt6.
/Sune
___
Development mai
On 2012-11-28, Labs, Torsten wrote:
> Hello,
>
> does anybody know something about a possiblity to use C# for programming Qt=
> 5 and Qt Quick?
> I know this sounds funny :-)
I would expect the people behind Qyoto (Qt4 mono bindings) will move on
to Qt 5 sometime in the future.
iirc Qyoto (a
On 2012-11-14, Taipale Juhani wrote:
> Hi all,
>
> Qt 4.8.4 Release candidate 3 packages are available at http://releases.qt-=
> project.org/digia/4.8.4_RC3/
My first attempt at using the windows thingie made me notice this:
it says during install
This package requires MinGW with GCC 4.4 ...
On 2012-11-14, Christian Kandeler wrote:
> On 11/14/2012 12:17 PM, Sorvig Morten wrote:
>> QtConcurrent is done. The implementation is not good enough to be used as a
>> base for further development.
>
> Can you be a bit more specific? What are the general problems and why
> can't they be easily
On 2012-10-31, Poenitz Andre wrote:
> This is not about "overriding someone". This is about ranking the user
> experience of the majority of users higher than the convenience of a
> handful of Linux distribution packagers - half which will do their own
> renaming anyway, no matter what the offi
On 2012-10-30, Thiago Macieira wrote:
> 1) QML environment variables
> The variable for import paths has been versioned from QML_IMPORT_PATH to
> QML2_IMPORT_PATH. But I have not changed any of the other variables. We need
> a
> decision from the team familiar with the engines and the meanings
On 2012-10-19, André Pönitz wrote:
>> Really. I really want, both as a Qt contributor and a Qt packager to
>> ship a pristine Qt. Please help me make it happen.
> Demanding to be relieved from that burden is one thing. Demanding to
> use an approach that will break thousands of other projects is
On 2012-10-19, Oswald Buddenhagen wrote:
>> I have, as a distributor, frequently gotten 'hate' in #qt for providing
>> switchable qmakes.
>>
> using (debian style) altenatives for that is pretty stupid.
I guess that proves my point quite good...
> as i've already written about three times, this
On 2012-10-19, Poenitz Andre wrote:
> User support could then be:
>
> "write qmake5 to build Qt 5 things"
no. it would be "if you compiled Qt yourself or if you downloaded the
built editions from digia, write qmake to build things. if you gotten
from your linux distribution write probably
qma
On 2012-10-19, Alberto Mardegan wrote:
> 3) Provide a script to switch, per user and maybe even per $PWD, what
> version of Qt /usr/bin/qmake should generate the makefiles for.
I have, as a distributor, frequently gotten 'hate' in #qt for providing
switchable qmakes.
And from a 'user support' P
On 2012-10-18, Giuseppe D'Angelo wrote:
>> The following are user applications and they have not and will not be
>> renamed:
>> qdbus
>> qdbusviewer
>> assistant
>> designer
>> linguist
>> creator
>> pixeltool
>
> I would remove creator from
On 2012-09-28, Stephen Kelly wrote:
> On Friday, September 28, 2012 13:25:42 Thiago Macieira wrote:
>> I've already contacted several downstreams: Sune for Debian, Will for
>> OpenSUSE, Raphael for FreeBSD; the Fedora people were the originators of the
>> bug report and have posted here.
>>
>> Al
93 matches
Mail list logo
