Some Questions to Orientations with Gluon:
Can you detect an Orientation switch with Gluon?
My current way of detecting is a size listener on the GlassPane, which is not ideal.
Can have two different FXML/Views per Orientation?
Normal switching when the orientation changes = easy
BUT
what about switching to the correct view when switchView() is called e.g. from NavigationDrawer? (switchView cannot be overriden since it is final...)
starting the app in landscape mode cannot be handled in any nice way, can it?
The best way would be if Gluon supported View switching dependant on orientation on their own (just implement it in the switchView method).
Related
Is Autolayout needed to setup for any subview, if my application only support one orientation (e.g., landscape right), applied for all UIViewControllers?
Yes, of course in the case of using animation I agree. But for the normal case, do I need AutoLayout?
Note: I am using XCode7, Swift, ios9
Understanding Auto Layout
Auto Layout dynamically calculates the size and position of all the
views in your view hierarchy, based on constraints placed on those
views. For example, you can constrain a button so that it is
horizontally centered with an Image view and so that the button’s top
edge always remains 8 points below the image’s bottom. If the image
view’s size or position changes, the button’s position automatically
adjusts to match.
This constraint-based approach to design allows you to build user
interfaces that dynamically respond to both internal and external
changes.
Unless you are making an app for one specific screen size, you will want to
use Auto Layout.
Use cases:
You want to support different size classes.
You want to support different screen sizes.
The content displayed by the app changes.
The app supports internationalization.
The app supports Dynamic Type (iOS).
Most of these changes can occur at runtime, and they require a dynamic
response from your app. Others, like support for different screen
sizes, represent the app adapting to different environments. Even
through the screen size won’t typically change at runtime, creating an
adaptive interface lets your app run equally well on an iPhone 4S, an
iPhone 6 Plus, or even an iPad. Auto Layout is also a key component
for supporting Slide Over and Split Views on the iPad.
Auto layout is not required at all. Even for multiple orientations.
However, If you don't use it, you'll have to manage placement for all the different sized devices yourself. So you might as well use it.
I would like to change the screen size of the ARC-Welder chrome-extention to a 7inch screen - displayed on my pc - to test an app on different screen sizes.
Can this be done using for example the meta-data input?
Similar to a question that I asked recently but I think shares the same answer. It seems that there are few choices when it comes to form factor, and based on the answer to my question I think that you can only use the three form factor presets for now.
(from #Elijah Taylor)
The size of the window is not configurable per activity*, but the orientation is. The two options in ARC Welder that control the window are:
Orientation: This is either landscape or portrait, which will be the default orientation for your app. However, if you set a screenOrientation on your Android activity, this can override the orientation per activity, with the window rotating to compensate. There is a performance cost to rotating this way because the plugin will be rotated via CSS.
Form Factor: This is one of phone, tablet, or maximized. This controls the overall size of your app globally.
but for Chrome 42 and up you can use the metadata {"resize": "reconfigure"} to allow arbitrary user resizing. Your app must be able to relayout with a variety of aspect ratios and resolutions in this mode.
My question at:Android ARC app for chrome, set size of windows for different Activities/Layouts
You can Use this MetaData :
{
"resize":"reconfigure"
}
just thought i'd mention that there is also "formFactor": "fullscreen" if want to test full screen it also works with "resize":"reconfigure"
I was reading Apple Watch Human Interface Guidelines and i'm curious if there is any way in displaying custom UI elements, other than those provided by default by Apple (like tables, buttons or labels). How did they managed to do this:
Did they use images?
While we haven't seen everything that Apple are doing with the core Watch OS apps, it is already clear there are many API functions that they are reserving for their own use at this stage. It's almost certain they were using some of those API functions to create these views.
There is no way to create truly custom UI elements with the current WatchKit API (i.e. entirely new custom classes doing custom drawing). That said, with some creativity, it would be possible to create most of the interface you depict with the current tools available to third party developers. This is almost certainly not the way Apple created it, but you could:
Create a group.
Put inside the group a button with a background image that represents one state of the coloured circle.
At runtime, visually animate the button image as needed by swapping through multiple images that rendered the various states of progress of the circle x colour options. Yes, the starting point would be thinking about 360 images for the circle states x the number of tints. (It is possible to apply a tint to a template image in WatchKit, but as far as I am aware you cannot apply a gradient.)
Add two labels to the group for the large number and subscript, and align both of these to be centred vertically and horizontally in the group.
You can set the tint of the page title at top left by setting the global tint of the application. By changing the global tint at runtime you could change these for each page.
It is not currently possible to change the colour of the page dots at the bottom. These are not set by the global tint and it is not possible currently to change these programatically.
Apple have indicated that later in 2015 third party developers will be able to build fully native apps, but even then, they have not given any indication of whether the API functionality available to us is broader, or whether our API will be essentially the same as it is now, with the one addition that at least some of the current WatchKit App Extension code will be able to run on the device when the iPhone is not present/charged.
I've got the task to program a graphical network editor application as a university project. For that I need three types of items/controls. A circle shape, a rectangular shape and arrows to connect the other shapes (the whole thing works somewhat like MS Visio in some ways). The shapes/controls need some additional features like moving, scaling a context menu etc. Also I need to have full control over the graphical representation of these objects i.e. I want to 'draw' them myself or at least be able to modify them as I need.
I am using JavaFX and have little to no experience with it. So I was wondering, what would be the best way to implement these custom controls. It is required to use JDK 7, so using SkinBase and BehaviourBase is not an option, since they are private before JDK 8.
I was thinking about subclassing Path or Canvas to use as my controls. But I know too little about the implications to make an informed decision.
Could someone give me some advice, which base classes to consider and what implications that might have?
Thx alot.
This answer is just going to be advice, there is no real right or wrong answer here. Advice is necessarily opinionated and not applicable to all situations, if you don't agree with it, or it doesn't apply to your situation, just ignore it.
Sorry for the length, but the question is open-ended and the potential answer is complicated.
I was thinking about subclassing Path or Canvas to use as my controls.
Don't. Favor composition over inheritance. Have a control class which implements the functional interface of the control and works regardless of whatever UI technology is behind it. Provide the control class a reference to a skin class which is the UI representation of the control. The skin will specify how to render the control in a given state (getting the control state from the associated control object). Also, the skin will be the thing which responds to user manipulations, such as a mouse presses and instructs the control to change its state based upon the mouse press - so the skin knows what control it is associated with and vice versa. In the control class have bindable properties to represent the control state.
A simple example of this is the Square and SquareSkin from this tic-tac-toe game implementation.
For example, imagine a checkbox control. The bindable property of control might be an enum with states of (checked, unchecked, undetermined). A skin might render the checkbox as a square box with a tick mark to represent the checked state. Or maybe the skin will render a rounded edge with an X. The skin could use whatever technology you want to render the checkbox, e.g. a canvas or a collection of nodes. The skin registers listeners for mouse clicks, key presses, etc. and tells the checkbox control to set its check state. It also has a listener on the check state and will choose whether to render the check tick based on that state.
The key thing is that the API interface to the checkbox is just a checkbox control class with a check state. The way the UI is handled is abstracted away from the checkbox API, so you can swap the UI implementation in and out however you want without changing any other code.
Subclassing Path is quite different from subclassing Canvas. For the situation subscribe, I would definitely favor subclassing a Shape node (or Region) as opposed to a Canvas. Using Nodes, you automatically have a really rich UI rendering and event model, bindable property set and and painting framework which you won't get with a Canvas. If you don't use Nodes, you will likely end up trying to re-create and build some parts of the Node functionality in some sub-standard way. Canvas is great for things like porting 2D games or graphing engines from other frameworks or building things that are pixel manipulators like a particle system, but otherwise avoid it.
Consider using a Layout Pane for your control skin, e.g. a StackPane or something like that. The layout panes are containers, so you can place stuff inside them and use aggregation and composition to build up more complex controls. Layout panes can also help with laying out your nodes.
Anything which subclasses a region like a Pane can be styled via CSS into arbitrary shapes and colors. This is actually how the in-built checkbox (and other controls) in JavaFX work. The checkbox is a stack of two regions, one the box and the other the check. Both are styled in CSS - search for .check-box in the modena.css stylesheet for JavaFX. Note how -fx-shape is used to get the tick shape by specifying an svg path (which you can create in an svg editor such as inkscape). Also note how background layering is used to get things like focus rings. The advantage of using CSS for style is that you can stylistically change your controls without touching your Java code.
so using SkinBase and BehaviourBase is not an option
Even though you have decided to not use these base classes (which I think is an OK decision even if you are targeting only Java 8+), I think it is worthwhile studying the design of the controls in JavaFX source. Study button or checkbox, so you can see how the experts do these kind of things. Also note that such implementations may be overkill for your application because you aren't building a reusable control library. You just need something which will work well and simply within the confines of your application (this is the reason I don't necessarily recommend extending SkinBase for all applications).
As a minimum read up on Controls on the open-jfx wiki.
It is required to use JDK 7
IMO, there is not much point in developing a new JavaFX application to target Java 7. There were many bug fixes for Java 8, plus new and useful features added. In general, Java 7 is a sub-optimal target platform for JavaFX applications. If you package your application as a self-contained application, then you can ship whatever Java platform you want with your application, so the target platform doesn't matter.
IMO deployment technologies such as WebStart or browser embedded applications (applets), which can make use of pre-installed java runtimes on a system, are legacy deployment modes which are best avoided for most applications.
Still, there might be a situation where you absolutely must have Java 7 due to some constraints outside your control, so I guess just evaluate carefully against your situation. If you have such constraints and must build on a stable, legacy UI toolkit which works with runtimes released years ago, you could always use Swing.
From oracle, the Path class represents a simple shape and provides facilities required for basic construction and management of a geometric path while Canvas is an image that can be drawn on using a set of graphics commands provided by a GraphicsContext.
Which means the user can use canvas to draw the required shapes as the user wants.
On of the basic ways I can say would be as follows:
Use canvas as it will help and allow for custom user "drawing". Creating menu buttons for the circles, rectangles, arrows etc. like in MS Paint. Onclick drag function on the canvas can be used for "drawing".
Circle and Rectangle are available in the libraries which you can use
You can use arrows like the way used here.
I think its the same example as you want to create.
Custom controllers and context menus can be created too docs.oracle.com
Scaling and Moving can be done by binding drag function to a scale
or translate animation. Mousepressed and Mousereleased can be used to track the coords to draw the shape in.
This is my advice, you can use the control prototype.Or an application or design tool which can provide you the targeted control or a icon with circle shape, a rectangular shape and arrows. I don't know how my advice work. You can try it.
Is there any Cocoa control that is capable of drawing tile maps with multiple layers and multiple texture sources which can also intercept touches into single tiles? Having multiple layer support is not a real requirement but an optional feature (the views could still be stacked). Hardware acceleration is not needed at all.
So far I have toyed around with NSMatrix, IKImageBrowser and NSCollectionView but non of them felt like a good solution for the problem. Ideally I need an control similar to the one in Tiled.app. Is there anything, third party or built-in, or do I have to handcraft this control?
I fear that you will be hardly able to find a ready-to-use control for managing tile maps.
If I had to implement something like that on my own, I would consider using CATiledLayer, since this is the closest thing to a tile map control that I know of.
From CATiledLayer Reference:
CATiledLayer is a subclass of CALayer providing a way to asynchronously provide tiles of the layer's content, potentially cached at multiple levels of detail.
There is a nice sample by Bill Dudney (the author of "Core Animation for MacOS and the iPhone"). This sample could provide you a solid foundation for your own project, though it only displays one single PDF, allowing you to zoom in the area you clicked on (this requires rereading the tile at a different detail level).
Another interesting introduction can be found here. This is more step-by-step, so you might start with this.
Finally, on Cocoa is my Girlfriend there is a nice article, although it focuses on iOS, but you may find it anyway relevant.
Cocos2D supports building mac applications now
Article on cocos2d stating this: http://www.cocos2d-iphone.org/archives/1444
Aee here for how to do it: http://chris-fletcher.com/tag/cocos2d-os-x/
Aee here on how to use TMX tile maps with Cocos2D to build tile based maps: http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:tiled_maps
This means you can use the power of Cocos2d and you will have to write much less code to get to where you want with a tile based map.
If you don't want to use Cocos2D:
It seems you would have to code it yourself, but it shouldn't be too hard to do.
First you can create your .TMX file using the tile editor "Tiled.app" then you would need to parse the XML using a standard xml library for Cocoa.
To lay out the tiles use a UIView for the overall container and then create a tile class that holds your tile display information and responds to clicks the tile class should extend UIView. For the tile class allow the assigning of a click delegate and assign your ViewController as the click delegate for all tiles so you can handle clicks easily with the clicked tile being passed to you.
Loop through your xml data and create and position the tiles in the overall UIView by using the tiles width/height and your tilemaps rows/columns.
I think in about a day or 2 you could have the tile map being rendered and clickable using the standard TMX format which will allow you to edit your map in "Tiled.app"
The TMX standard is covered here: https://github.com/bjorn/tiled/wiki/TMX-Map-Format
route-me might fit the bill.