On 16 November 2015 at 23:47, Sebastian Kügler <[email protected]> wrote: > On Friday, November 13, 2015 23:59:09 Lubomir I. Ivanov wrote: >> > 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. > > Next question: Would you want to have a go at it? :) > > (I'm happy to review, of course.) > >> > 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. > > Good to know the backstory. > > Factoring Dirk's reply in, I think an edit overlay is the way to go here, > that means we > can concentrate on presentation in the divedetails page and focus on editing > and > input in the edit page, this allows us to make both really good instead of > having to > make compromises in each. > >> 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? > > Not knowing anything about windows, you already suggest to try the default > theme, > so try that. Otherwise, specifying width and height in the top-level item > works: it puts > the initial window at exactly that size. > > You can also try using Window (effectively a QQuickWindow) as top-level item, > see > attached example. Let us know what works for you, then we'll put that in > (shouldn't > cause any problems), and it makes your life easier. >
so the exact error message when using ApplicationWindow (as is in main.qml): setGeometryDp: Unable to set geometry 160x1200+720+426 on ApplicationWindow_QMLT YPE_74_QML_111/''. Resulting geometry: 160x885+720+426 (frame: 4, 23, 4, 4, cus tom margin: 0, 0, 0, 0, minimum size: 0x47, maximum size: 16777215x16777215). it crashes after a while. my desktop resolution is 1600x900px. changing ApplicationWindow to Window and keeping everything else makes it work. i can now resize the window to any size. attached is a screenshot. thanks lubomir --
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
