Please consider this simple rebol2 code to illustrate my problem:
REBOL []
a: make face [
offset: 0x0
color: yellow
size: 20x20
]
b: make face [
offset: 0x0
color: red
size: 60x60
pane: reduce [
make a [offset: 0x0]
make a [offset: 10x10]
make a [offset: 10x20]
]
]
view layout [
box 200x200 white with [
pane: reduce [
make b [offset: 0x30] ;; one 'instance' of b
]
]
]
The main point here is for a layout (or face) to be able to display a bunch of faces inside its pane block in such a manner that multiple creations of the same face (b in this case) should be possible. The shown code works well, and the only instance (let me call it this way) of b is displayed as it should be.
But now suppose I change the code so I have, say, 2 instances of b:
view layout [
box 200x200 white with [
pane: reduce [
make b [offset: 0x30]
make b [offset: 0x10]
]
]
]
At this point I get the error
** Script Error: Face object reused (in more than one pane): none
** Where: view
** Near: show scr-face
if new [do-events]
From the message I presume here that face b is somehow getting reused and messing exactly what I'm trying to achieve. I've done lots of research on this and at some point I found that it is possible to get around it by cloning (using make) the face to be passed to pane; that's what I thought I was doing, but with no success at all.
Given this scenario, my question is: how can I go about to solve this? is rebol2 ok to provide this "face-instantiation" or it is best to try something else outside rebol2 (perhaps rebol3)?
Any help will be greatly appreciated.
Rebol2 is definitely ok to do this.
When you MAKE b second time you are using the same instance of a. That is the problem.
You can write a function that creates necessary faces and append them to a block and return.
Don't forget to create 'a (first face) every time.
Additionally, check for the iterated faces in the documentation.
Here I added an example:
REBOL []
make-pane: func [ofst [pair! block!] /local a b faces] [
a: make face [
offset: 0x0
color: yellow
size: 20x20
]
faces: copy []
either block? ofst [
foreach o ofst [
append faces make a [offset: o]
]
] [
append faces make a [offset: ofst]
]
b: make face [
offset: 0x0
color: red
size: 60x60
pane: faces
]
]
view layout [
box 200x200 white with [
pane: make-pane [5x30 0x10 20x5]
]
]
You can change the function to get more parameters to change color and other facets as well.
As is already pointed out the problem is that a is reused, not b!
the layout function uses a field called init for handling things like this. As I understand it init is first bound to the face and then called with do after the face itself is instantiated (at least partially).
In this case I would be using the style command in layout (still partially using face object a )
view layout [
style
bb box 60x60
with [
append init [
pane reduce [
make a [offset: 0x0]
make a [offset: 10x10]
make a [offset: 10x20]
]
]
]
panel 200x200 white [
at 30x0 bb
at 0x0 bb
]
]
The other alternative, a bit more similar to your would be:
b: make face [
offset: 0x0
color: red
size: 60x60
init: [
pane: reduce [
make a [offset: 0x0]
make a [offset: 10x10]
make a [offset: 10x20]
]
]
]
view layout [
box 200x200
with [
append init [
pane: reduce [
make b [ offset: 0x0 do init ]
make b [ offset: 0x60 do init ]
]
]
]
]
Note that init is manually called within the make clause in this case. I'm not all sure why it is needed.
Finally the everything could elegantly be solved with style
view layout [
style a box yellow 20x20
style b panel red 60x60 [
at 0x0 a ; we can in this style use the just defined a style
at 10x10 a
at 10x20 a
]
at 0x0 b
at 0x60 b
]
I've said on a comment that I would get back to share my findings and I think I got something interesting. As well pointed out by #endo64, iterated faces are tricky and perhaps not best suited to what I intended to do when I first asked the question - to achieve a simple/straigthforward way to instantiate objects thru panels.
I came up with the code bellow, which implements a kind of instantiator. It was inspired in part by the face-maker approach of #endo64 along with some tinkering with iterated faces. This instantiator has a core limitation, which is not accepting multiple types of objects being passed to the constructor to be created at same pane.
Anyway, I found it was an interesting exercise and I would like to post it here in case it could be useful to someone.
I use the same code from the question, now solving/circumventing the limitation of creating multiple b objects inside the main layout pane. a and b now hold an instantiator object, which receives an object to create inside its pane and a block of positions (pair offsets) where objects should be placed.
a: make face [
offset: 0x0
color: yellow
size: 30x20
]
b: make face [
offset: 0x0
color: red
size: 100x100
inst_b: _instantiator/new reduce a [10x10 10x70 80x80 30x30] ; instantiator here
pane: get in inst_b 'pane_function
]
The instantiator code is:
_instantiator: make object! [
_obj: copy []
_offsets: copy []
new: func [
obj [object!] "object to create inside pane"
offs [block!] "instances offsets"
][
make self [
_obj: obj
_offsets: offs
]
]
pane_function: func [face index] [
if integer? index [
if index <= length? _offsets [
_obj/offset: to-pair reduce [_offsets/:index/x _offsets/:index/y]
_obj
]
]
]
]
Code for main layout is:
_inst: _instantiator/new reduce b [0x0 50x50 130x130] ;;3 b objects are created in the positions indicated in the pairs block
_lo: layout [
mybox: box 500x500 white with [
offset: 0x0
pane: get in _inst 'pane_function
]
]
view center-face _lo
Related
is there a way in SpTextPresenter and SpTextInputFieldPresenter to use ctrl+S (or cmd+S in mac) to save text entry?
Old pharo components (notably old spec but this comes since before, when components when built on plain morphic) were allowing to "accept" contents by pressing <meta+S> (and cancelling the edition by using <meta+L>).
Is there a way to replicate this behavior in current Spec?
Spec permits to define "default" submit/reset events to provide old behavior.
Ok, this is an easy answer, but somehow complicated for some users since they expect the old behavior and this does not works like that anymore.
So first I need to explain why old behavior is no longer available :)
Thing is, old components where a mix of different things: they were plain UI widgets while also model containers in the spirit of old MVC (Model View Controller). So they mixed Model (the keep of the status) and the view (the display of the component). For this reason, old components had an initial status and you needed to accept that status (you got it, using <meta+S>) to make it being transferred to the model part.
This mix of responsibilities lead to different workarounds, like the addition of the autoAccept property to make the component copy its value it change of it.
When designing the new version of Spec we decided to not keep this behavior that looked hacky and was causing inconsistencies in the API and in consequence anyone wanting the old behavior need to make it explicitly in their own components.
So, how to get old behavior?
This is the question after all!
We have added two methods to allow somehow same functionality: whenSubmitDo: and whenResetDo:. This can be combined with whenTextChangedDo: to mark/unmark a dirty property.
Here is an example, Is a little bit verbose, but is also easy to create your own components with this behavior predefined and reuse them in your application:
app := SpApplication new.
"If using Morphic"
app addStyleSheetFromString: '.application [
.dirty [ Container { #borderColor: #red, #borderWidth: 1 } ],
.notDirty [ Container { #borderColor: #transparent, #borderWidth: 1 } ]
]'.
"If using GTK (you need to choose one, both options are not possible at the same time)"
app useBackend: #Gtk.
app addCSSProviderFromString: '
.dirty {
border-color: red;
border-width: 1px; }
'.
presenter := SpPresenter new.
presenter application: app.
presenter layout: (SpBoxLayout newTopToBottom
add: (textPresenter := presenter newTextInput) expand: false;
yourself).
text := ''.
textPresenter
text: text;
whenTextChangedDo: [ :aString |
aString = text
ifTrue: [ textPresenter removeStyle: 'dirty'; addStyle: 'notDirty' ]
ifFalse: [ textPresenter removeStyle: 'notDirty'; addStyle: 'dirty' ] ];
whenSubmitDo: [
text := textPresenter text.
('Submitted ', text) crTrace.
textPresenter
removeStyle: 'dirty';
addStyle: 'notDirty' ];
whenResetDo: [
textPresenter
text: text;
removeStyle: 'dirty';
addStyle: 'notDirty' ].
presenter asWindow
title: 'Example submit/reset text component';
open
This will produce (with the Gtk3 backend) this output:
I moving my project from dagre-d3 to cytoscape.
Cytoscape.js is really more flexible and will allow more powerful control but for now, I just can't have the edge rendering as I want.
Here is the dagre-d3 version:
Here is the actual cytoscape:
As you can see, it's almost the same except :
cluster are not in the same order (not a big deal).
edge can overlap the whole graph.
The last one is my main issue, I just can't find a way to tell cytoscape to make edge as parallel as possible like dagre-d3.
I'll try to use segments edges (that seems the right edge type) but I can find a way to configure it.
Also try taxi one but label are unreadable.
Here is a full example : https://jsfiddle.net/uqtahcfs/
{
"elements": {
"nodes": ...,
"edges": ...,
},
"style": ...,
layout: {
name: "dagre",
rankDir: "LR",
animate: false,
fit: true,
padding: 50,
spacingFactor: 1.2,
},
pixelRatio: 1,
minZoom: 0.2,
maxZoom: 2
}
Any way to have segment that look like parallel ?
The cytoscape.js-cola documentation for the gapInequalities element of a layout dictionary says:
gapInequalities: undefined, // list of inequality constraints for the gap between the nodes,
// e.g. [{"axis":"y", "left":node1, "right":node2, "gap":25}]
How do you set up the objects that specify the nodes in the values of left and right?
maxkfranz helpfully pointed out here that these objects need to be collection objects. These contain references to specified nodes ("elements") and are created by querying the cytoscape.js "core object". What's not clear to me is, given that the layout object needs to refer to the node elements, and the elements should not be added to the graph before the layout tells how to render them, how do you properly set up those collection objects?
For example, to specify that node b should be placed above node a, what goes in place of ???a??? and ???b??? in the code below?
cy = cytoscape({
elements: [
{ data: { id: 'a' } },
{ data: { id: 'b' } },
. . .
],
layout: {
name: 'cola',
gapInequalities: [
{ axis: 'y', left: ???'a'???, right: ???'b'???, gap: 25 }
. . .
],
. . .
}
. . .
]);
In this case, the answer can't be cy.$id('a') and cy.$id('b') because the cy object hasn't been created yet. You could get around that by creating the cy object without elements and then calling cy.add() to put them in. But then what goes in the layout object that's passed to cytoscape()?
I'm new to both cytoscape.js and cola.js, so I'm most likely just missing some very elementary idea here. A simple example showing what function calls set up the objects and the sequence in which to call them would probably do it. In my application, nodes and edges are added to the graph gradually, and the animation needs to show them being added, so not having all the elements set up at the start makes more sense, anyway.
Since your nodes and edges are added gradually, you can create cy object without elements and layout object. Then when new nodes come, you can add them to the graph and apply layout.
After initialization of the cy object, every time new nodes come, apply the following :
cy.add(...);
cy.layout({
name: 'cola',
gapInequalities: [{ axis: 'y', left: cy.$id("a"), right: cy.$id("b"), gap: 25 }],
...
}).run();
Why isn't my ListView's selection changed event being triggered?
I expect the selected True attribute to generate the InputContentType message.
However it doesn't.
listview =
select [ Html.Events.on "change" (Json.Decode.map InputContentType Html.Events.targetValue) ]
[ option [ value "instructions" ] [ text "Content Type" ]
, option [ value "Article", selected True ] [ text "Article" ]
, option [ value "Video" ] [ text "Video" ]
]
In the actual code that I have (which isn't shown here), I programmatically select an item in my listview based on a value in a textbox. This is done in my view function.
Is there a recommended practice for achieving this?
Appendix:
type Msg
= ...
| InputContentType String
Currently you have a fixed selection. Since the selected attribute is set to always True then "Article" will always be selected. My suggestion would be to add selected to every option, and then make the Bool contingent on which option is currently selected in the moment, information that should be stored in your model.
I'm currently working on a gallery to my photos. Besides some bugs, I'm finished with the gallery but I want to add a new and fresh theme to the front page. I'm very in love with how Google+ shows the photos and I'm asking you now, how can I add this effect for my list of photos in my own gallery?
Thanks in advance.
It appears they are using divs for rows and sub-divs for columns. You could, dynamically or statically, determine which of these formats you will have for the row:
//1
[ ][ ]
[ ][ ]
[ ]====
[ ][ ]
//2
[ ][ ]
[ ][ ]
From there style the rows and columns as { float: left } and make images { width: 100% }. Here is a tutorial on infinite scrolling image galleries: http://net.tutsplus.com/tutorials/javascript-ajax/how-to-create-an-infinite-scroll-web-gallery/ and you could just fade in images as you display them.