I believe our proposed change (containing locale backend , date and time
classes and related widgets) is ready to be merged (maybe after some minor
improvements)
I would like to ask someone to review this change:
https://codereview.qt-project.org/#/c/182341/
Cheers,
Soroush
_
Greetings
Good idea (: it would be great to have RPC integrated into Qt...
There was a similar project (Qt Remote Objects was the name if I'm not
mistaken). Don't know the details, seems they are planning to provide
a transparent remote API around Qt's Signal/Slot mechanism... You may
want to hav
Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's
not much to do. Either we implement calendars as factory classes
operating on QDate, or adding to QDate's API, there is not much work
left to do.
___
Development mailing list
Developme
> Now question is that: witch form is preferred? Will be case (1) break Qt
> rules?
I don't know about QML and it'd design principles, but I like option
3. Though it must take that calendar instance as second argument I
suppose:
var out = date.toString("/MM/dd", Qt.JalaliCalendar); // Is
Just submitted first change set:
https://codereview.qt-project.org/#/c/182341/
Planning to add three more calendars and separate index array (to
reduce overhead on locales) this week. Persian calendar is still one
day behind. Seems to be related to julian day base. The original
algorithm counts d
Sorry for being noisy on this list, but I think we have several issues
needed discussion before going further.
First we have a design decision to make, the minimal set of
assumptions on calendaring systems. According to my minute research we
can assume following facts on every calendar that is in-
Greetings all, and happy new year
> Issue: Q(Date|Time)+ think day-changes happen at midnight. Some
>
calendar systems think they happen at sunset or sunrise; these are both
> rather tricky, as their time depends on date and latitude [3] - and I'm
> not sure what they do about days when the sun
>
> Can you elaborate on the reasons that prevent any change of that kind in
> QDate? Maybe they can be worked around?
>
>
According to
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
Adding a member to struct or class is not possible without brea
>
> If you change QDate's internals, you have to wait for Qt 6.
>
> You can add to its API before then, though.
>
Hmm... I'll think of something else then.
I thought these changes are backward compatible (API only), though it seems
I'm mistaken. Maybe missing something about ABI compatibility: Ad
>
> I don't expect the calendaring system to require any changes to QDate
> internals. It stores a Julian day, that's all.
>
That's why we need to change QDate. The idea is to remove all calendar
calculation code out of the QDate (into QCalendarSystem possibly). I think
QDate already has been bloa
On Thu, Dec 15, 2016 at 3:53 PM, Edward Welbourne
wrote:
> Soroush Rabiei wrote:
> > Nowadays, almost all major programming frameworks support calendar
> > globalization. We are a small group of developers working with
> > non-Gregorian calendars and we believe Qt must s
1. Purpose
Nowadays, almost all major programming frameworks support calendar
globalization. We are a small group of developers working with
non-Gregorian
calendars and we believe Qt must support this too. This proposal discusses
details of our plan (and early implementation) to add support for mu
Hi list
IIRC webkit source is not supposed to be compiled with C++11. So I turned
off new standard in configure script:
.\configure ... -no-c++11 ...
Trying to compile I got this error:
In file included from Platform\CoreIPC\Connection.h:35:0,
from Platform\CoreIPC\Connection
Ah sorry, I can't reproduce the issue after a complete recompile. I think
the problem is caused by an outdated object file that is not marked to be
recompiled by mingw32-make. Looks like mingw32-make and make (in Linux)
work differently... (Any problem with time-stamps on windows?)
I did some test
Hi everybody
I'm using a custom build of Qt 5.1.1 compiled with GCC 4.8.1 on
Windows (MinGW builds x86_64). For some performance reasons I have to
enable "-O3" flag until my project is ported out of Qt. The Qt was
built with C++11 support.
When program tries to append an item to a container it
Hi development list
Is it possible to compile Qt3D without compiling Qt itself? Installed
version of Qt is 4.8.0 which is installed via debian packages.
thanks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/l
16 matches
Mail list logo
