...(I left the whole post here, becuase IMHO it's very important for "context-to-the-question", and IMHO it's a good question.)
Mark spaketh: > Hi, > > I'm developing a calendar in QML and thus far it seems to going quite well. > Making a view with 12 months visible or a full month to select a day > isn't an issue. Works wonderful in QML. > > The place where i hit real big QML issues (or actually the lack of > components) is when i want to make the day overview. Go to google > calendar or the calendar in your emailing application and you notice > that you can select some cells in the day overview. Those selected > cells will become the "appointment" or event or whatever. That part is > close to impossible to implement in the current QML. > > Take this as an example if you don't know what i mean: > http://photos.appleinsider.com/Lionical4.png > > What i want to do is the following. I want users to be able to select > some cells in QML which will then be a event and stored somewhere. > Obviously the user can also have overlapping events or multiple events > at the same time - like other calendars allow as well. > > The issues i run into are: > - dynamic elements don't have a ID thus that can't be used. That > prevents selecting it and dragging/dropping the event on another date. > - there is no sane way to select some elements in a list or repeater > without doing all kinds of tricks > - once the selection is made, how can i lay an item on top of that > selection? Dynamic element? > - there don't seem to be any elements in QML that are suited for this > > So, is Qt 5 going to be of help here in making it easier? I doubt > that. Is there another way how i can make this work? Or do i need to > make special QML elements in C++ that are maintained in C++ as well > (id wise)? I'd hate to make that in C++ if it's even possible. It is > possible with QWidgets, but that kinda defeats the point of using QML. > > I hope this makes some sense since it's quite difficult to describe the > issue. > Incase you want to test my current testing code, clone: > git://gitorious.org/qmlcalendar/master.git > > in main.qml uncomment: > > CalendarDay > { > anchors.fill: parent > } > > And comment the CalenderMonth part. > > Cheers, > Mark > Very good overview. Great question. I don't have a *specific* answer, but I have *specific* observations: (1) QML does this with properties. (2) Where is your "model"? Specifically, it takes time to "re-think" how to design without IDs. You can implement a model and use IDs, but you actually don't need them. Rather, what you otherwise could achieve with IDs you can achieve with: (a) properties on QML items/components (implies "categories-of-stuff", including "categories-of-one-item") (b) aggregation of QML items/components into "larger" items/components (a given "item" can have only one "parent", but it can have an infinite number of "step-parents"; for example, you could have a "step-parent" that "contains/references" all the "items-being-added-to-the-current-calendar-entry-being-created") The QML technology is "bound-properties-on-objects". Because it's not (the historic) "imperative-actions/updates-after-user-event", everything you describe must be expressed declaratively. For example, the following might work, and is actually similar to how most "gestures" APIs work: (possible declarative assertions): *- "selected" things register themselves in the "current-transaction-(step-)parent" (NOTE: Unlike QWidgets, a QML "parent" has *no* direct implication for "child-placement" [e.g., like "layout"], although you can do that if you want.) *- "selected" things have a "front" Z-order *- "selected" things have a "highlight-decoration" ...You can even do something like, *- "selecting" this "cell" creates a "buddy" that references the originating-cell/item (and Z-order-placement-and-highlight-implied-by-the-original-item), and that "buddy" is part of the accumulated-items that will become the "calendar-event". Under a "gestures" API, a "gesture-event" accumulates all gesture-points-and-actions while the gesture is created, and when the gesture is "completed/recognized", the whole logical "gesture-event" is "popped" (processed, and converted into the logical action). For your model, you would incrementally accumulate-information-into-a-transaction (e.g., "for scheduling an event"), and when "done", the "MyCalendarEvent" would have all that information. That brings me to the second point: You've got to have a model. It sounds like you're "all-QML" at the moment (no C++). That should be fine, but you must still code some kind of "data-structure(s)" to describe your calendar-and-events, *somewhat-independent* from the GUI components. This "separation" gives you "room-to-breathe" as you perform lengthy transactions, permit "un-do", handle data-validation that permits you to "unwind" something that can't be completed, etc. I tend to prefer my model in C++, because that gives me more expressive separation from the QML/GUI reflection/display. The QML technology is fantastic for the "dynamic-property-reflection" to/from QML and my C++ model. Under this scenario, yes, it's code: The C++ model has all the "atoms/classes" to fully describe the calendar, and the QML has all the "atoms/classes" to "represent" the calendar. If you want to do it all-in-QML, that should work fine (you don't need C++), but I'd guess you'd need similar: -- The QML "items" to represent the "view", and -- the QML (or Javascript) "components" to represent the "model". Apologies if I misunderstood your question... ? Specifically... The issues i run into are: > - dynamic elements don't have a ID thus that can't be used. That > prevents selecting it and dragging/dropping the event on another date. > You should set "properties" on those elements-selected-for-a-calendar-entry, or possibly have a "(step-)parent-aggregator" that accumulates all the "things" associated with that calendar-entry-being-defined. > - there is no sane way to select some elements in a list or repeater > without doing all kinds of tricks > Selecting an item can create a "buddy-item" that highlights the original item (e.g., "Z-order", alpha-blend), and that "buddy" can be parented by the "calendar-event-being-defined", while positioned based on its buddy-origin-item. Or, the "calendar-event-being-defined" can "imply" those things that should be "selected/decorated" within other lists and repeaters. > - once the selection is made, how can i lay an item on top of that > selection? Dynamic element? > You can set "properties" on the item-in-list-or-repeater (which probably "imply" decorations), or you can create a "buddy" and decorate the original (e.g., "Z-order" and "alpha-blend"). - there don't seem to be any elements in QML that are suited for this It seems like you need to "accumulate-a-bunch-of-stuff-while-you-define-a-calendar-entry", and at the end of this "transaction", you will have a "MyCalendarEntry". That seems like "model" stuff to me, and you'd need to write that application-specific class/item (unless I misunderstand?) Good luck! --charley
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
