Subsurface 4.7 / 5.0

Dirk Hohndel dirk at hohndel.org
Sun Jan 22 12:59:36 PST 2017


On Sun, Jan 22, 2017 at 06:54:58PM +0100, Marco Martin wrote:
> > > 
> > > remind me: Didn’t we run into some problems („bugs“) in Kirigami for
> > > which by sticking with an old version we give up any hope of them ever
> > > being fixed? Not that I tried too hard myself (and having no idea what
> > > the differences between 1 and 2 are besides the numbers).
> > 
> > There are tons of bugs in Kirigami. As in TONS. That said, who believes
> > that any of them will get fixed in Kirigami 2? I see no indication of
> > that.
> 
> have them been reported somewhere?

We have mostly reported them to you and Sebastian.

> i didn't hear feedback from subsurface in the last few months (we have a 
> bugzilla tracker on bugs.kde.org, product kirigami)
> https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1417206&product=kirigami&query_format=advanced

I think I filed one there at some point, but am no longer certain. With my
job change the last six months have been a bit quieter. The things that I
recall reporting include (and I never know if they are QML bugs or
Kirigami bugs)

- scrolling problems at the bottom of the dive list when things suddenly
  go blank or wildly jump around
- crazy layout issues where in grid layouts things get cut off at the
  right edge - we ended up working around all of them by no longer
  allowing the grid to resize
- no cut and paste to text fields
- positioning issues with the keyboard (so if I tap on a text field and
  the keyboard opens, the positioning is all wonky, the target text field
  sometimes ends up under the action button, etc)
- there were other input issues (switching to the special email-address
  keyboard doesn't work)
- problems with the horizontal scrolling between dives (very uneven look
  and feel at times)

That's off the top of my head, six months after I stopped spending time on
this.

> > In the meantime, to explain the difference... it's a little more than just
> > the version number. Kirigami 2 is based on Components.2 instead of
> > Components. Which means that pretty much every single class that we have
> > used, every graphical element has changed. It's a complete API break. And
> 
> api changes in kirigami itself are kept to a minimum, in particular those 
> properties or signals that name would conflict with something implemented in 
> the base QQC2 class.
> I doubt porting the whole application to kirigami2 and qtquickcontrols2 in one 
> go would be the way to go as would be indeed an huge undertaking, but should 
> be perfectly fine to mix things together.

That's not something that is made obvious in the documentation. Oh, right.
Which documentation. There ain't any. You're just supposed to know what to
do.

> I think, if one wants it to be ported to kirigami2, this should happen at a 
> separate step, and none of the qtquickcontrols1 usage be touched yet.
> 
> And then if one wants to port the qtquickcontrols usage as well, that should 
> happen gradually, like one file at a time.
> 
> > the documentation of what needs to get done to port things is "it's not
> > hard to port". Seriously. I have yet to find anything that gives you even
> > the faintest instructions.
> 
> there are those few api changes (opened->sheetOpen should be the only real 
> user facing change in our code, other api change but minimal may have come 
> from rebasing classes to things coming from qtquickcontrols2)
> in general, is not much more than a search and replace of import 
> org.kde.kirigami 1.0 into org.kde.kirigami 2.0 

Because of the QML bugs with revisioned fields, there are a ton of
problems - for example you can't give padding to a Kirigami.Label (you get
the incredibly helpful "versioning error"). This is with Qt5.7.1

> > What I have figured out so far by looking at the crash logs is this:
> > - no more styles
> > - no more control object for buttons
> > - no more ScrollView
> > - opened turns into sheetOpen
> > - no more Action
> > - ComboBox is completely changed
> > - TableView appears gone
> 
> yes, those are changes in QtQuickControls2 (apart from sheetOpen), some things 
> will get back (like action in the short term and tableview in the long term) 
> some won't. We had quite some issues of basing on top of a moving target as 
> well.
> every single thing that is needed from QtQuickControls1 can still be used and 
> as far i know even if not really actively developed won't go away for the 
> whole Qt5 lifecycle, so there is plenty of time to adapt.
> It is perfectly fine, and deisgned to be to import two versions of 
> qtquickcontrols in the same qml file, at the same time, with a different 
> namespace

Again, complete lock of documentation of how do this (that I could find)

> import QtQuick.Controls 1.0 as Controls
> import QtQuick.Controls 2.0 as Controls2
> 
> > I spent about 15 hours on that and the result is an app that doesn't work.
> > It doesn't open the keyboard when you tap on an input field. None of the
> > ComboBoxes work. All of our model handling code is broken. It makes me
> > want to cry if I think how much time I have spent on this.
> 
> is there a branch somewhere that can be tried?

Yes, I posted about this a couple of days ago, but based on what you say
in this email I don't think that's the right approach because I thought I
had to switch to Controls.2 everywhere - and that's what really causes
most of the pain.

/D


More information about the subsurface mailing list