On 13 November 2015 at 23:14, Sebastian Kügler <se...@kde.org> wrote: > Hah, nice! > > For my taste, the code especially in SwipeArea is a bit low-level, making it > hard to maintain. The javascript running on the change notifier signals may > also slow down the whole thing. In my experience, especially input logic can > be quite brittle, not necessarily something you want to maintain for a long > time.
i'm used to writing/maintain things like that in languages/frameworks where built-in components are not sufficient for all the crazy client UI extravaganza in commissioned projects. e.g. a BuiltInComponentX covers 90% features but the client wants it to do 10% backflips in such a way that the time investment of modifying the existing component is more than re-writing the whole thing from scratch. > > On the other hand, QtQuick's ListView provides already what we need. So here's > a slightly different approach: we use a listview will delegates sized to fit > exactly in the viewport. We re-use the divelist's model for this listview as > well, and we set the listview to snap to items when scrolling: pronto: we > a=have swiping. > > This means that we show usually one item (and when swiping left/right between > items two partial items), so we can tell the listview to keep the number of > items rendered in check, ListView is equipped to do that with the > ListView.cacheBuffer property, which essentially says: "keep delegates for > this number of pixels left and right ready", so it will dynamically render > more items and delete the delegates as needed. > As a bonus, we don't have to copy a whole lot of data between divelist and > details view, we just set the detail's listview.currentItem to whatever the > user picked in the overview list (and possibly avoid animations). > > Do I make sense to you? If not, proof-of-concept attached. It's quite minimal > and only shows the very basic mechanism. > nice...so ListView pretty much does what's required here out of the box. also Flickable and MouseAreas in the delegate item *just work* - i've just tested that. plus the buffering, which is a great bonus! as long as there no performance issues, this is pretty much good to go in the source. > I quite like what you have done in the delegate. I'd like to split viewing and > editing dives into separate UIs, one optimized for viewing, one optimized for > editing (e.g. showing the profile in the editing page is not very useful, on > the other hand the TextEdit widgets in the details view make it visually quite > heavy. We should probably do something like to the current details delegate > (and repurpose / cut down the current detailswidget purely for editing. > for the main application something which was an important topic at some point in time (discussions between Dirk and Tomaz mostly) was to be able to edit in place. this can be seen in the MainTab class ATM. so i'm not sure if everyone will agree on a separate dive edit page for the mobile UI, but this can be solved with a DiveEdit overlay of sorts - i.e. when you swipe the ListView to a dive, click over the details and a rectangle opens on top of static texts with some TextEdit fields...or a DiveEdit can simply replace the static text container until the editing is finished. not sure about the exact implications and if this is the best choice. --- BTW, i'm getting a crash on Win32 when i build the mobile application. it says that the main application rectangle is wrong and enters a long loop of allocating GB of memory, until it runs out. if i manually set "width" and "height" in the ApplicationWindow of main.qml it ignores them but it runs in a huge window! the UI looks quite bad here, but that's probably because i'm using the Windows XP them on Windows 7. :-) any idea how to run the UI in a reasonable desktop resolution e.g. 480x800px? lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
