On Tuesday, 8 August 2017 08:49:36 PDT Edward Welbourne wrote:
> Thiago Macieira (7 August 2017 06:14)
>
> > ... there are bigger problems with the implementation, starting with
> > QAbstractCalendar having a static protected QMap member.
>
> That's my fault. We're going to need some way for QML
Thiago Macieira (7 August 2017 06:14)
> ... there are bigger problems with the implementation, starting with
> QAbstractCalendar having a static protected QMap member.
That's my fault. We're going to need some way for QML/V4 to get at
calendars; and I want to ensure our design leaves scope for cl
On Saturday, 5 August 2017 05:08:23 PDT Soroush Rabiei wrote:
> 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://
On Saturday, 5 August 2017 05:08:23 PDT Soroush Rabiei wrote:
> 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://
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
_
On Monday 02 January 2017 09:21:25 Lars Knoll wrote:
>>> I wonder whether we can't keep handling of different calendars
>>> completely outside of QDate. Something similar to what we've done
>>> with QString/QLocale. So QDate would continue unchanged and only
>>> support the standard Gregorian calen
Edward Welbourne wrote:
> (Coptic being also from Ethiopia)
Uh, no. Coptic is from Egypt. According to Wikipedia, "Its years and months
coincide with those of the Ethiopian calendar but have different numbers and
names."
Kevin Kofler
___
Deve
I had remarked:
>> That shall complement Soroush Rabiei's work on the C++ side:
Hamed Masafi (30 January 2017 21:07) replied:
> Yes, that's right. I'm trying to port Soroush's calendar mechanism to
> qml side of Qt.
Good.
>> If I understand Lars correctly, he prefers an API where the calendar
>>
Soroush Rabiei (30 January 2017 11:04) wrote:
> Speaking of the API, I wish to share an idea about not to put calendar
> implementations in a plugin subsystem.
I should clarify: when I spoke of calendar systems in plugins, I wasn't
suggesting we should do that as the normal mode for commonly-used
Sorry to have left this thread dangling for so long.
A vast flood of code-review came my way ...
Now to work my way back through the thread, staring at the end,
so all in JavaScript land:
On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote:
>> My prefer option is form (3)
>> We can add an enumer
On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote:
> My prefer option is form (3)
> We can add an enumeration to global space.
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "-MM-dd");
I would prefer to not modify standard APIs if we can avoid it (unless we
have a good
> That shall complement Soroush Rabiei's work on the C++ side:
Yes, that's right. I'm trying to port Soroush's calendar mechanism to qml
side of Qt.
> If I understand Lars correctly, he prefers an API where the calendar
> object carries methods that act on a date and any further arguments it
> may
On segunda-feira, 30 de janeiro de 2017 15:43:30 PST Soroush Rabiei wrote:
> 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.
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
On Mon, Jan 30, 2017, at 08:59 AM, Hamed Masafi wrote:
> I'm working on qml support of calendar system,
> for porting this mechanism to qml we have two option:
Have you considered whether Date.prototype.toLocaleDateString could be
of use for this? See:
http://ecma-international.org/ecma-402/3.0/in
> 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
Hamed Masafi (30 January 2017 08:59):
> I'm working on qml support of calendar system,
That shall complement Soroush Rabiei's work on the C++ side:
https://codereview.qt-project.org/182341
http://bugreports.qt.io/browse/QTBUG-58404
Prior discussion:
http://lists.qt-project.org/pipermail/developmen
I'm working on qml support of calendar system,
for porting this mechanism to qml we have two option:
1)
Add a global object to jsengine?
Somthing like that :
var date = new Date;
var cal = new JalaliCalendar;
var out = date.toString(cal, "-MM-dd");
In this case JalaliCalendar is a new global
Em terça-feira, 17 de janeiro de 2017, às 10:22:57 PST, Edward Welbourne
escreveu:
> Jake Petroules
>
> > Eddy, "draft" does not do what you think it does. This is why no one can
> > see the change.
> I think you are addressing the wrong person.
> Soroush created the review (as a draft) and added
Allan Sandfeld Jensen asked:
> Are you aware of KCalenderSystem?
Yes - Sergio Martins helpfully brought it up a couple of weeks ago:
http://lists.qt-project.org/pipermail/development/2017-January/028241.html
Current plan is roughly to upstream it. Debate remains as to whether it
should sit outsi
Jake Petroules
> Eddy, "draft" does not do what you think it does. This is why no one can see
> the change.
I think you are addressing the wrong person.
Soroush created the review (as a draft) and added me as a reviewer.
That enabled me to add Frederic.
> Please remove "draft" status and add "WI
On Thursday 15 December 2016, Soroush Rabiei wrote:
> Currently there is no support of any calendar system other than Gregorian.
> Gregorian calendar is widely used in western countries. However most
> countries
> in Middle-east, Asia and Africa use other calendar systems. Unfortunately
> there
> i
Eddy, "draft" does not do what you think it does. This is why no one can see
the change.
Please remove "draft" status and add "WIP: " at the front of the commit message
instead so we can all take a look.
Thanks,
> On Jan 16, 2017, at 5:07 AM, Edward Welbourne wrote:
>
> On Sunday 15 January
On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote:
>> Just submitted first change set:
>>
>> https://codereview.qt-project.org/#/c/182341/
Frédéric Marchal replied:
> I'm seeing an error: "The page you requested was not found, or you do
> not have permission to view this page."
I've just ad
On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote:
> Just submitted first change set:
>
> https://codereview.qt-project.org/#/c/182341/
I'm seeing an error: "The page you requested was not found, or you do not have
permission to view this page."
Frederic
_
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
Le 13/01/2017 à 15:46, Edward Welbourne a écrit :
Soroush Rabiei
1. All calendaring systems, show dates in three levels: Year, Month and Day
2. The week is 7 days. It may start at any of these days.
French revolutionary calendar:
https://en.wikipedia.org/wiki/French_Republican_Calendar
Not that
Edward Welbourne wrote:
> Soroush Rabiei
>> 3. Number of months in all years are fixed.
>
> Is there no lunar calendar with occasional extra months ?
Of course there is. Any lunar calendar adjusted for consistency with the
solar year necessarily has occasional intercalar months. The Jewish cale
Soroush Rabiei
> Sorry for being noisy on this list, but I think we have several issues
> needed discussion before going further.
I should note that Lars still holds to the view that we should keep this
out of QDate: which seems to imply roughly just upstreaming
KCalendarSystem, albeit with the op
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-
I observed:
>> Issue: Q(Date|Time)+ think day-changes happen at midnight. [...] Has
>> secular society shifted the day boundary to midnight in practice ?
Soroush replied:
> Indeed they do the simplification needed to adopt modern lifestyle.
OK, good - then we have an excuse to keep the simple mod
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
On 05.01.2017 17:12, Edward Welbourne wrote:
Sérgio Martins very helpfully linked to KCalendarSystem - thank you.
One of the things we should clearly aim for is to make it easy for
KCalendarSystem to (when its developers care to and can find the time,
with no pressure to do so) adapt to use QCale
Well, I've missed a long and lively discussion while I was away. I've
now caught up with e-mail, digested the thread and done some (but by no
means enough) background reading; that's left me with some jumbled
notes. This shall be long - let's start with the thread (and fit some
of those notes int
On segunda-feira, 2 de janeiro de 2017 12:01:49 BRST Frédéric Marchal wrote:
> There is more to it than converting a date to a string:
>
> * Add N days to a date.
> * Find the number of days in a month.
> * Compare two dates.
> * Count the number of days between two dates.
All but the second one
On 2017-01-02 11:01, Frédéric Marchal wrote:
(...)
There is more to it than converting a date to a string:
* Add N days to a date.
* Find the number of days in a month.
* Compare two dates.
* Count the number of days between two dates.
Hi,
Have you seen KCalendarSystem ?
https://api.kde.org
Sure, that there’s more to do than just the examples I listed. Still, design
wise it might be a good idea to have this functionality in a class separate
from QDate. We’ve done the same design decision for QString (having no locale
specific functionality in QString), and this worked out rather ni
On Monday 02 January 2017 09:21:25 Lars Knoll wrote:
> I wonder whether we can't keep handling of different calendars completely
> outside of QDate. Something similar to what we've done with
> QString/QLocale. So QDate would continue unchanged and only support the
> standard Gregorian calendar. In
I wonder whether we can't keep handling of different calendars completely
outside of QDate. Something similar to what we've done with QString/QLocale. So
QDate would continue unchanged and only support the standard Gregorian
calendar. In addition, we have a QCalendar class, that can be construct
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
>
> 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
On Saturday 17 December 2016 11:16:24 Thiago Macieira wrote:
> On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote:
> > The idea is to remove all calendar
> > calculation code out of the QDate (into QCalendarSystem possibly). I think
> > QDate already has been bloated and knows more
>
> 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
On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote:
> > 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.
If you change QDate's internals, you have to wait for Qt 6.
Y
>
> 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
Em quinta-feira, 15 de dezembro de 2016, às 21:10:19 PST, Sune Vuorela
escreveu:
> 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 make it easier to
> implement my two missing pet features:
> - Partial dates
> - Dat
Ch'Gans wrote:
> Boost have them all: date/time, calendar, time zone, time period and
> time duration
> Date/Time is a very tricky subject, why not rely on boost implementation?
>
> http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html
Because it would suck for Qt to de
On 16 December 2016 at 10:10, Sune Vuorela wrote:
> 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 d
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 support this too. This
> >
Op 15/12/2016 om 22:10 schreef Sune Vuorela:
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 whi
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
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 support this too. This
> proposal discusses details of our plan (and early implementation) to
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
53 matches
Mail list logo