[Interest] QML select/drag/drop like a calendar.

[Charley Bay]

...(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120708/7a9f1db0/attachment.html>