[
https://issues.apache.org/jira/browse/PIVOT-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978237#action_12978237
]
Chris Bartlett commented on PIVOT-682:
--------------------------------------
Greg Brown added a comment - 05/Jan/11 08:25 PM
> ... sheets don't ever slide in from anywhere but the top of a window. As a
> Mac user, I am familiar with and like that convention.
In which case you would be free to never use the new style to alter the default
slide direction!
Respectfully, it almost sounds like you are suggesting this should not be
possible in a Pivot class named Sheet, because it is not possible in the Mac
component named Sheet which was the inspiration. (Although I am not trying to
put words into your mouth)
Would you be happier with a Pivot subclass of Sheet which had a skin that
extended TerraSheetSkin with the new style & associated logic to perform the
directional animation? That would meet the requirement and is what I have
already done in my own code (due the convenience of subclassing library
components/skins rather than altering and maintaining a modified source branch)
> Trays are also supported on OS X, but they are not widely used and work
> slightly differently ...
> The proposed version of Tray would slide in from the sides of the display and
> would be display-modal.
As mentioned before, I am not aware of anyone having requested the
functionality to be display modal, The requirement was just to be able to
control the slide animation direction of a Sheet.
> Since many Pivot apps use a single main maximized window, the user experience
> of a Tray in this case
would be identical to that of your proposed Sheet.
What about the apps where I have multiple Frames and want the possibility for
each to have a Frame modal 'Sheet/Tray/whatever' that slides in from a
direction other than the top? This suggestion would not meet the previously
stated requirement.
> If you simply want content to slide in and out from the side of a window, why
> not do it within the window itself?
Because 99% of the functionality already exists within Sheet and this seems to
be a fine example of the purpose of styles. Perhaps it is not and that is
where the confusion is arising?
> You could use a collapsible tab pane for this, or maybe a hypothetical
> vertical Expander.
Or I could use a Sheet that can have its Slide direction controlled through a
new style :)
Personally, I do not want any extra content painted on the screen as would be
the case with a TabPane or Expander. I just want something that looks and
behaves like a Sheet to be able to slide in from another direction, and does
not require any additional GUI cruft on the parent window.
> Does the content actually need to be modal?
Yes, but only modal to its parent. However I can see the value of changing
Sheet to allow a Display as a parent, and also to allow a sheet to be closed
with a minumum of effort (as shown in the attached tutorial code)
Greg Brown added a comment - 05/Jan/11 09:03 PM
> ... modal windows like dialogs and sheets require input from the user, and
> users read from top to bottom.
That user input might be as simple as pressing any key, or clicking the mouse
anywhere within the bounds of the modal window or over its parent. It needn't
be a complicated form to complete.
Granted users read top to bottom, but that seems moot when the top of the Sheet
content will be the last part that is made visible due to the downwards slide
animation. Once the animation has completed (regardless of which direction it
slides from) the window content would be at its most visible for users to read
from top to bottom, or scan images.
> Visually, the eye will be directed towards the top first - the fact that it
> is horizontally centered serves to emphasize the importance of the
> interaction.
I feel that the slide animation itself would serve to draw the eye.
This technique is widely used in TV advertising, for example when watching
sports on TV in countries where the game is shown without breaking for
commercials. An info bar/ticker/banner will slide in from the bottom of the
sceen, (compressing the main content slightly, as modality obviously does not
apply). I have seen this in TV sports shown in Europe, Asia, Africa, USA &
Australia, so it seems widespread. The animation distracts the viewer and
draws the eye to the new content, if only for a split second.
> A modal window positioned anywhere else will be confusing, and will not
> convey to the user that immediate attention is required.
If this is really the case, then doesn't it follow that all modal windows in
Pivot should only ever appear bound to the top of its parent? I'm not a fan of
inflicting restrictions on the potential uses of Pivot components, so would
resist this idea (as I seem to be doing right now!).
If a GUI designer feels strongly about modal window placement, it can be
controlled. If they don't, then I don't see why it should be dictated to them.
People should be free to create ugly or horrible UI experiences if they so
desire!
The Pivot project could conceivably create its own recommendations along the
lines of Apple's Human Interface Guidelines, but I they should only ever be
guidelines. In any case, it would not be feasible to build in all of the logic
to ensure that those guidelines are never broken.
This could start with some content on the Wiki as a series of short 'how to'
articles/paragraphs explaining the best or Pivot way to acheive a particular
GUI effect.
example 1) Request user input in a modal dialog = Use a Dialog or Sheet, or
roll your own with a Window, but place it at such and such a location unless
there is a reason not to.
example 2) Add the ability to show & hide TableView columns at runtime = Add a
context menu handler to a TableViewHeader, do bounds checking, populate the
menu, then add/remove selected columns from the underlying column sequence.
(This is veering off topic, so I will leave it there)
> This means that the Tray concept is probably flawed as well, unless it is
> implemented as a modeless window (and, now that I think about it, that is
> exactly how Trays are implemented on OS X). I'd suggest that we consider
> other alternatives for sliding non-modal content into view.
Again, sliding non-modal content into view was not the original requirement.
Sheet could also be extended to be non-modal and possibly hide itself after a
certain period of time. This would provide behaviour that might be referred to
as a Notification (as seen in email applications). I can see the value of a
dedicated class for that in order to configure the modality and handle the
timings, but could also envisage a static helper method on Sheet/Prompt/Tray to
achieve the same thing.
Perhaps others have opinions they wish to contribute as I don't think I have
anything further to add for now. I have already added this functionality to my
code base, so the outcome of this ticket is unlikely to affect me personally.
> Enable slide-in direction specification in the case of Sheet component
> ----------------------------------------------------------------------
>
> Key: PIVOT-682
> URL: https://issues.apache.org/jira/browse/PIVOT-682
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-terra
> Environment: all
> Reporter: Zsolt Putnoky
> Fix For: 2.0.1
>
> Attachments: 20101221.TerraSheetSkin.slide_direction.patch,
> sheets_tutorial.jpg, sheets_tutorial.zip
>
>
> Dear All,
> As discussed over the forum, it would be a nice feature to be able to define
> from which side the Sheet component is sliding in. The discussion can be
> found:
> http://apache-pivot-users.399431.n3.nabble.com/Sheet-sliding-in-from-the-left-right-bottom-Is-there-a-way-tp2032319p2032319.html
> Your work is highly appreciated,
> Regards,
> Zsolt 'MSafiri' Putnoky
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
