Re: [Development] New library in qtbase

[Robin Burchell]

On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote:
> Short summary, we have three possibilities:
> 1) Own module (and current implementation)
> 2) One “core" module and one GUI module to separate concerns for system
> not requiring a GUI connection (Jake’s suggestion)
> 3) Put everything in QtGui and implement the stuff in the QPA parts with
> the implication that a QGuiApplication will be required.
> 
> Can we come to an agreement about which one to implement ?

My own vote would be tending towards 3 once the concept is nailed down.
The existing change looks a little confused from a quick skim, e.g. you
have a QCocoaNotifier which seems to be public API, but this is not the
way I would expect to see this (at least, not in QtGui); I'd expect to
see a "notification" class without any platform specifics, as far as
possible, which then hooked into platform-specific code to "do its
magic".

As the "magic" would tend to be platform-specific, QPA seems to be the
logical place to me; this then also allows a platform implementer to
provide their own custom notification handling, should it be required –
thinking more on the embedded or new platform front here, which is
typically where QPA comes in anyway, where you may not necessarily have
existing services or standards to follow.

I can agree that it's "sad" to have to switch a QCoreApplication to a
QGuiApplication once you need something in it, even if you don't have a
GUI to present (though really, is this a common problem?), but aside
from puritanical concerns, does that actually cause many concrete
issues?

So, considering that, and as it's a problem that already exists for
non-graphical applications to have to interact with images/clipboard,
for syntax highlighting and other text manipulation, etc, I don't think
that adding another case to that problem is a death sentence. I think
it's an extension of a minor inconvenience, but I don't think that
arbitrary splitting of a feature or class is a good way to address that.
It leads to a harder to use & understand API for little gain as I
imagine it, though it is hard to say without a concrete suggestion on
API to review.

In the much longer term, on a separate tangent from your work, it might
be interesting to think about rearranging things to properly address
this problem if the gain is worth it, but even then, that starts to get
tricky & requires a lot of care and research, especially when you
realize that not everything you may want can be done without a windowing
system: clipboard access, for instance, I'd say is almost certainly
impossible to do without a windowing system on all platforms

The same may apply to presenting notifications. Do you know the specific
requirements of the APIs for, say, Windows/macOS/iOS/Android? If any of
those (or future platforms) required the WS, then you'd essentially be
left with a useless API on anything that did not have a QGuiApplication.

I'd say that ultimately, requiring a QGuiApplication instance is a
lesser evil than providing an API that won't work universally.

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

[Robin Burchell]

Hi,

On Sun, Jan 15, 2017, at 12:24 PM, J-P Nurmi wrote:
> There have been some discussions about rewriting the entire item-view
> framework. I personally believe that would be best done in a major
> release. :)

I guess you're talking about the generic positioner-based view stuff
here, but I wasn't thinking quite so ambitious. That is indeed one thing
that is still bouncing around my head, but I suspect it will stay there
for some time more :)

More generally, I don't disagree that such a thing would be a major
version change, or at least, done in a separate import. Anyway, I'll try
write a longer mail about some of my thoughts on this stuff so they have
a place in the public record, split off from this thread, as it is
definitely a bit of a tangent.

> +1 to having a branch for it (do you have a name in mind? wip/itemviews?
> wip/tableview?)
> 
> I was thinking wip/itemviews, but I don’t mind wip/tableview either. :)

If your specific goal here is to provide enablers for tableview, then
I'd go for wip/tableview.

> Having more branches could be an option. All the tasks are somehow
> connected to each other, though, so I was thinking that it might be
> easiest to do it all in the same branch to avoid excessive conflicts and
> merging between multiple WIP-branches. The last two, SortFilterProxyModel
> and TreeModelAdaptor, would be the most logical ones to split to separate
> branches, but on the other hand, they also need to be implemented so that
> they play well with the rest.

Yes, that's pretty much the sort of division I was thinking; and
especially if Pierre-Yves can help with contributing on the SFPM part,
perhaps that's a good candidate for doing "separately". I understand and
agree with the need for unity, of course, but perhaps communication can
help to some degree there. Anyway, it was just a suggestion. I'll leave
the "how" to you people, you know the details of this work better than I
:)

> There’s so much to do that there is no way we could make all this happen
> before the 5.9 feature freeze in two weeks. :)

Text doesn't quite convey the emotion I meant that statement to evoke
;-); but I guess then you're thinking something like 5.11 (potentially
earlier, if the planets align correctly)? Again, I'm not expecting
promises here, just a rough idea would be a help so I can know when I
need to start trying to pay closer attention to anything touching the
area.

Thanks again.

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

[J-P Nurmi]

Hi,

> On 14 Jan 2017, at 19:20, Mark Gaiser  wrote:
> 
> That new TableView is really going to support models that derive 
> QAbstractTableModel? Without any changes required on the model side? So if it 
> works in QTableView (C++ widget) then it will work in the new TableView (QML 
> component)?
> That would be a big win!
> 
> Would the view also have transition support?
> The current TableView [1] component doesn't have it, the GridView [2] 
> component does, but it basically only eats list models and requires role foo..

Yes, we’re well aware of the limitations and quirks of the TableView in Qt 
Quick Controls 1. :) QAbstractTableModel support is considered as a requirement 
for the new TableView. I’m quite confident we can base the new TableView on the 
same item-view framework ListView and GridView use, so it can support the same 
item view transitions and so on.

> Do you plan the new TableView to be a styled component (like one of the many 
> other control components) or a bare component where the user needs to define 
> the delegates for the contents, header and sidebar?
> My preference would be a bare component.

The plan is that the new TableView would be on the same line with ListView and 
GridView. The visual delegates are left to the user to provide. For those who 
want ready-made styles, we provide a bunch of simple styled delegates in Qt 
Quick Controls 2.

--
J-P Nurmi


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

[J-P Nurmi]

Hi,

On 14 Jan 2017, at 17:24, Robin Burchell 
> wrote:

I have a longer mental list of things that concern/bother me with
current model/views (some of which we've already discussed), maybe I
should try write that up in some form, if you think it might find it
helpful, but as I don't know how much time I'll be able to dedicate to
making this happen you may prefer me to hold my tongue :-)

There have been some discussions about rewriting the entire item-view 
framework. I personally believe that would be best done in a major release. :) 
I’m not planning to start writing a new item-view framework from scratch at 
this point, but refactor the internals so that it would be possible to reuse 
the same item view transitions etc. for a two-dimensional table view. In 
essence, I would like to avoid changing the basic principle how QQuickItemView 
works, but just split the reusable parts to a more abstract base class, for 
example. Ideally we wouldn’t have to touch ListView and GridView at all, and 
they'd continue to work at the same performance they have today.

+1 to having a branch for it (do you have a name in mind? wip/itemviews?
wip/tableview?)

I was thinking wip/itemviews, but I don’t mind wip/tableview either. :)

A thought, that came to mind while thinking about naming, though:
there's a lot of features listed here, and I would expect that they will
mature at different rates as some of them are more standalone, while
others might require more extensive (and careful!) work on the existing,
rather complicated code.

As a result, I start to wonder whether a single branch for all of this
makes sense, or whether it may make sense to do some smaller pieces
either directly on dev, or to use more than one WIP so that it's easier
to land stuff "when it's ready" rather than turning into a huge pile.

I have great confidence in you, of course, just trying to make life
easier along the way, so if you don't want to do this or feel that it
wouldn't be helpful to you, feel free to ignore the idea :)

Having more branches could be an option. All the tasks are somehow connected to 
each other, though, so I was thinking that it might be easiest to do it all in 
the same branch to avoid excessive conflicts and merging between multiple 
WIP-branches. The last two, SortFilterProxyModel and TreeModelAdaptor, would be 
the most logical ones to split to separate branches, but on the other hand, 
they also need to be implemented so that they play well with the rest.

(PS. I know you won't want to make hard promises, especially this early,
but do you have any idea what kind of timeframe you have in mind for
landing? Fingers crossed for "not 5.9"! ;-))

There’s so much to do that there is no way we could make all this happen before 
the 5.9 feature freeze in two weeks. :)

--
J-P Nurmi


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

[Soroush Rabiei]

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 day 1 as a base date.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development