Re: [Pharo-users] protobufs for Pharo
On Mon, May 11, 2015, at 12:27 PM, Paul DeBruicker wrote: If you've gotta have prorobuf then you've gotta have protobuf but there is a thrift implementation (https://thrift.apache.org/) and also a message pack implementation (https://code.google.com/p/stomp-serializer/) There are unfortunately a lot of protocols (including the one I mentioned used by RethinkDb) that are protobuf-based, so using one of those won't work too well. If interfacing with a third-party tool *weren't* necessary, I'd honestly probably just use Fuel, anyway. --Benjamin
[Pharo-users] protobufs for Pharo
Hey all, Has anyone implemented protobufs for Pharo yet? I’ve not managed to find any examples, so I assume the answer is “no”, but I thought I’d check here before rolling up my sleeves and writing one myself. (My specific target here is to write a RethinkDB driver, so if someone has magically also done *that*, please let me know, too.) Thanks, --Benjamin
Re: [Pharo-users] Spur images
On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe s...@stfx.eu wrote: [snip] Apart from that, the tokenisation is not very efficient, #lines is a copy of your whole contents, so is the #split: and #trimmed. The algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye for performance might yield better results. So I was reflecting on this more. If String and WideString were immutable, then it'd be easy to avoid all of these copies; you could instead pass around very tiny objects that had only three members (a String, a start position, a stop position), and avoid copying very much data. It's that String and WideString are mutable that preclude that. For fun, since I know I won't mutate the stringsin this example, I actually did a quick spike where I replaced #copyFrom:to: with a new method I introduced called #viewFrom:to: that returned a StringView. I'll post the code when I have a chance to clean it up if there's interest, but it looks like it pretty handedly chops off 120-150ms from that runtime (i.e., double the speed). Has there been any thought to introducing some immutable collections? Or maybe I'm just missing them? They'd be useful not just for String and WideString, but really for basically any of the collection types. The implementation in most cases would be as simple as overriding #at:put: and friends to throw self shouldNotImplement, and then providing methods/classes like the one I introduced to allow taking advantage of the newfound immutability. If there's interest, I'd be happy to submit a Slice we could use as a concrete RFC of what this could look like. --Benjamin
[Pharo-users] Spur images
My apologies if this is already spelled out somewhere and I simply can't find it, but are there any Spur images for Pharo yet? I can only find Squeak ones. It's not a big deal either way; I was just playing with an algorithm that, after very heavy optimization, I was able to get down to about 278ms per pass (from ~700ms initially from a naive implementation). For contrast, the equivalent Python runs in ~80ms. Looking at MessageTally, it seems at least half of that 278ms is spent noodling around in WideStrings and other small things that the Spur object format ought to help with, so it'd be interesting to see how much of a speed boost that gives without any further work.
Re: [Pharo-users] Ridiculous we are
On Tue, 23 Sep 2014 08:51:54 -0400, Hilaire hila...@drgeo.eu wrote: Le 23/09/2014 14:09, Damien Cassou a écrit : I recently read documents about utf-8 encoding. In all of them, the author says that pathnames should be kept as is because you never know which encoding the filesystem uses. So, a filename should probably be a bytearray. yes, but a #é should be encoded in two bytes. As noted in my previous message, é could be represented as either one or two Unicode code points, and these in turn could validly be either two or three bytes in UTF-8. My gut says that $é should be U+00E9, because otherwise you should have to use two Characters ($e and $´), but you could legitimately argue otherwise as well, and at any rate, #é could definitely be either. This is likely the core of the issue you're hitting.
Re: [Pharo-users] Ridiculous we are
On Mon, 22 Sep 2014 17:58:41 -0400, Sven Van Caekenberghe s...@stfx.eu
wrote:
I also find the way some problems are reported quite disturbing. How
much testing did you do ? On which platforms ?
I can do this (in Pharo 3) without any problems (we're talking about
arbitrary Unicode characters in path names):
('/tmp' asFileReference / 'été') ensureCreateDirectory.
'/tmp/été' asFileReference exists.
('/tmp/été' asFileReference / 'Ελλάδα.txt') writeStreamDo: [ :out |
out 'What about Greece ?' ].
('/tmp/été' asFileReference / 'Ελλάδα.txt') exists.
('/tmp/été' asFileReference / 'Ελλάδα.txt') contents.
And in a terminal, I get:
$ ls /tmp/été/Ελλάδα.txt
/tmp/été/Ελλάδα.txt
$ cat !$
cat /tmp/été/Ελλάδα.txt
What about Greece ?
This is on Mac OS X.
So this part fundamentally works in the image and on one VM. There might
of course be problems in how paths are used in certain places or on
certain VM/platforms.
Focusing purely on Unicode itself (not the encoding systems), a letter
like é can be represented as U+00E9 (LATIN SMALL LETTER E WITH ACUTE), or
as U+0065 (LATIN SMALL LETTER E) followed by U+0301 (combining acute
accent). These will appear identical to the user, but are emphatically
*not* identical for most software. The way you're testing here, you will
not hit any error relating to this concept, ever, because you're using
Pharo for both generating and consuming the strings. At the very least,
we'd need to generate a file named été with both forms explicitly and
see what happens.
Things get even more exciting, though, because Unix says that file names
are simply arbitrary byte patterns that do not contain the null byte.*
Thus, you can trivially create a file named été using Latin-1 encoding,
and again using UTF-8 encoding, and again using UTF-7 encoding, and these
might all be shown to the user as identically named, but I guarantee you
that Pharo will not act sanely with all four of these. Even on Windows,
where things are a bit saner (NTFS mandates UTF-16), and where an explicit
normalization form is preferred (NFC), I just explicitly verified that I
can trivially inject other normalization forms into the file system.
Thus, you can still have two files named été that nevertheless have
different names as far as the OS is concerned.
In this case, as far as I can tell, Pharo assumes that all path names are
Unicode, and does not do any work to convert strings to or from the
various normalization schemes (looking in Path
classcanonicalizeElements:, Path classfrom:delimiter, and
FileSystemStorepathFromString: here).
There's therefore a pretty straightforward fix that Pharo could do:
1. Path would use ByteArrays as the actual canonical store, and
provide convenience methods to see what the array decodes to
in various encodings. The developer and application can make
decisions about what encoding system they want to use.
2. The VM likely needs to be modified to handle this (didn't check)
As much as I wish Hilaire provided more details in his bug report, it's
worth keeping in mind that not all users, or even all programmers,
understand the full implications of things like how various Unicode
normalization and encoding schemes interact in practice with Unix's very
vague concept of what a file name actually is, so I usually try to
approach these bug reports carefully and with an open mind.
--Benjamin
* On OS X, HFS+ uses UTF-16 with an Apple-specific variant of NFD, whereas
I do not believe this holds for e.g. UFS or FUSE-backed file systems, so
things are a bit subtler there, but the general rule holds.
Re: [Pharo-users] Ridiculous we are
On Wed, 24 Sep 2014 13:03:57 -0400, Sven Van Caekenberghe s...@stfx.eu wrote: Did you read the actual conversation in the issue ? https://pharo.fogbugz.com/f/cases/14054/Issue-with-path-with-accented-characters It has been renamed and there is a fix (as a change set, not as a slice, yet). Basically, there was a primitive call into a plugin that failed to do encoding. No, I apologize; I missed the bug link. Thanks for reposting it. Now regarding the issues you raised. Pharo does not do Unicode canonicalisation or any of that other fancy stuff (like categorisation, proper ordering and so on). This is another orthogonal and way more general issue. Regarding the pathnames encoding: if the OS itself does not know it, how can we ? That's actually the argument *against* using UTF-8 as the standard Pharo way to represent filenames--at least on Unix systems. If Pharo used ByteArrays to represent paths, with convenience methods for working with UTF-8 (since I do agree that's the most likely thing for a user/dev to want), then you'd be able to work with all files no matter what, *and* have a convenient way of doing so for the common case. This is an old discussion, and I do see both sides of it. In terms of SCMs, Mercurial and Git both just say it's a collection of bytes, whereas Subversion says it's Unicode code points. This has some uncomfortable implications for both systems when working on multiple platforms. --Benjamin
Re: [Pharo-users] Question on Spec
I will say it depends how you initialise your objects ;) The good way to do it is in the method `initializeWidgets` Could you post it so I can tell you a bit more? Ben On 06 Aug 2014, at 10:56, Mark Rizun mri...@gmail.com wrote: Hi, I'm writing tests for RewriteTool which I build with spec. I have a TextModel in this tool. When I do: /RewriteTool new openWithSpec/, /TextModel sourceTextArea/ is initialized, however in tests I don't want to open a tool, just want to initialize it. So I wrote /RewriteTool new/. Everything is initialized, but/ TextModel sourceTextArea/ is /nil/. And I don't know why. Any thoughts? Best, Mark -- View this message in context: http://forum.world.st/Question-on-Spec-tp4771958.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Question on Spec
On 06 Aug 2014, at 11:16, Mark Rizun mri...@gmail.com wrote: Actually in each:) I have a class AbstractPanel and there is: initializeWidgets self instantiateModels: #(#templateText #MyTextModel). templateText dragEnabled; text: self demoText; ast: (RBParser parseRewriteExpression: self demoText); aboutToStyle: true; model: self; menuOptionsSelector: #menuActions This should then be initialised :S Could you try to put a `self halt` here to see if you hit it when you initialise your main model? Ben P.S.: why did you need to subclass TextModel? Is there something missing you wanted to have?
Re: [Pharo-users] Question on Spec
On 06 Aug 2014, at 11:30, Mark Rizun mri...@gmail.com wrote: Yes it is invoked(I mean initializeWidgets in AbstractPanel) if I do: RewriteTool new. If you put the halt after `self instantiateModels: #(#templateText #MyTextModel).` can you confirm that templateText is not nil? And yes, I needed more functionality for TextModel Which ones? :) Maybe they deserve to be pushed into TextModel Ben
Re: [Pharo-users] Question on Spec
On 06 Aug 2014, at 11:52, Thomas Bany mun.sys...@gmail.com wrote: In short, when you call RewriteTool new, you have a fully initialized description of the GUI, but you don't have the GUI. Exactly :) The model hierarchy is made to be independent of the rendering framework behind. Ben
Re: [Pharo-users] Question on Spec
On 06 Aug 2014, at 11:50, Mark Rizun mri...@gmail.com wrote: No they don't:) I just replaced a menu of TextModel with my own, and added some ast support. Can’t the menu be changed dynamically in TextModel? Ben
Re: [Pharo-users] Question on Spec
Maybe you can manually set the Adapter? Ben On 06 Aug 2014, at 12:39, Mark Rizun mri...@gmail.com wrote: Maybe it can, but it's more convenient for me to subclass it So, how do I initialize it for tests without opening it with spec? 6 серп. 2014 12:00, користувач Benjamin benjamin.vanryseghem.ph...@gmail.com написав: On 06 Aug 2014, at 11:50, Mark Rizun mri...@gmail.com wrote: No they don't:) I just replaced a menu of TextModel with my own, and added some ast support. Can’t the menu be changed dynamically in TextModel? Ben
Re: [Pharo-users] Question on Spec
On 06 Aug 2014, at 14:11, Thomas Bany mun.sys...@gmail.com wrote: Going through the execution of 'openWithSpec', it looks like the method you are looking for is 'buildWithSpec'. It definitely instantiate the adapters as well as the morphs, with the root of the morph tree being nil. I can't tell you if everything will work as intended though, but I don't see why not. Benjamin developed Spec and might be able to answer that. `builtWithSpec` should definitely do it :) Finaly, I don't quite see what is wrong with opening a window in a test, as long as you send 'close' to your model at the end ? Usually you want tests to be runnable in headless mode :) Ben
Re: [Pharo-users] Spec - vertically stacked Menu(Group)Model
It is not yet supported, sorry :s Feel free to propose a solution to this :) Ben On 17 Jul 2014, at 18:24, Peter Uhnák i.uh...@gmail.com wrote: Is it possible to force MenuModel to display its groups (and group's items) vertically instead of horizontally? The use case is having button palette to click on. Both world menu and subMenu of MenuItemModel render it this way but it is all hidden in the depths of Morphic. Is there any way how to switch this behavior at Spec level? (Or should I make it from scratch?) Peter
Re: [Pharo-users] Spec - vertically stacked Menu(Group)Model
If you can add some Spec behaviour to match the morphic one, then it’s ok :) Ben On 17 Jul 2014, at 19:03, Peter Uhnák i.uh...@gmail.com wrote: Well, is this something that should be done on top of the existing solution, or should be Morphic be pushed away and use only Spec? Or just use Morphic for the very last item - Button and the rest with Spec? Currently every Menu[Group|Item]Model has it's morphic counterpart, but I'm not familiar with future of Morphic. Are we trying to get rid of it or just use an abstraction on top of it (Spec)? On Thu, Jul 17, 2014 at 6:47 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: It is not yet supported, sorry :s Feel free to propose a solution to this :) Ben On 17 Jul 2014, at 18:24, Peter Uhnák i.uh...@gmail.com wrote: Is it possible to force MenuModel to display its groups (and group's items) vertically instead of horizontally? The use case is having button palette to click on. Both world menu and subMenu of MenuItemModel render it this way but it is all hidden in the depths of Morphic. Is there any way how to switch this behavior at Spec level? (Or should I make it from scratch?) Peter
Re: [Pharo-users] Custom layout in Spec
On 13 Jun 2014, at 17:09, webwarrior r...@webwarrior.ws wrote: I implemented SpecTableLayout, which uses TableLayout policy. Cool :) Wasn't that hard, beacuse actual layouting *is* done in Morphic. It is not. That’s exactly why SpecLayoutFrame exists by example. You can convert Spec layout into morphic layout to use in the case of Morphic but this is decoupled. For example: I do not see your example here :S Is my Mail.app missing to load a file or did you miss to insert something ? Now I wonder how do I transfer these changes from Monticello to GitHub in order to make pull request? clone the repository (as you will do for any other github project) then serialise your code via Monticello browser using “filetree Then you can commit, push, pull request Thanks, Ben
Re: [Pharo-users] Custom layout in Spec
Ben On 16 Jun 2014, at 15:01, webwarrior r...@webwarrior.ws wrote: Wasn't that hard, beacuse actual layouting *is* done in Morphic. It is not. That’s exactly why SpecLayoutFrame exists by example. You can convert Spec layout into morphic layout to use in the case of Morphic but this is decoupled. Now I see what you mean. But my aim was to make a layout that works here and now with Morphic. Ok :) But one of the goals of Spec is to not be Morphic specific For example: I do not see your example here :S Is my Mail.app missing to load a file or did you miss to insert something ? It was just a section of code. Maybe your mail client doesn't show html? Could be :s It was the following: ^ SpecTableLayout row add: #toolbar wrapped: [ :e | e hResizing: #shrinkWrap ]; That sounds strange :) Ben View this message in context: Re: Custom layout in Spec Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Finding methods sending shouldBeImplemented within a package
Open Nautilus, right click on your package, ‘Choose Open restricted browser’ It would open a new Nautilus scoped to your package. Then in the code pane, just type ’shouldBeImplemented’, select the text and right click, and finally select 'Implementors' Ben On 28 May 2014, at 13:57, Markus Fritsche mfrits...@reauktion.de wrote: Hi, I am working on some NativeBoost bindings to a library. I am organizing my work along the API of a java binding of the same library. As nights go by, I created some methods that I didn't have yet use for as self shouldBeImplemented, writing the others with test first. What is the easiest way to find all methods sending shouldBeImplemented in my package? Best regards, Markus
Re: [Pharo-users] [Pharo-dev] Pillar in TextMate
Cool :) I will definitely have a look :) Ben On 20 Apr 2014, at 08:35, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Dear guys who use Pillar. I’m happy to announce that I’ve created a small bundle for TextMate. You can find it here: https://github.com/Uko/Pillar.tmbundle Also I’ve exported it to ATOM (new editor from github) package, but it’s crappy because ATOM lacks some stuff right not. Package is called: language-pillar, source is here: https://github.com/Uko/language-pillar I will be happy to hear your feedback, and add more features. Happy Easter! Uko P.S. (won’t be online for ≈30hours)
Re: [Pharo-users] Drag and drop items between list views
Sorry for the delay, I turn off my emails during the week end :) Out of this thread, I have made this post: http://spec.st/docs/drag_n_drop/ With a small change in the Spec code base (to not sort by default, but only when a sorting block is specified), it gives an example of how to do what you want :) (since it is not a crucial change, I do not think it will be introduced in 3.0, but the latest Spec image can be found here: http://benjamin.is-a-geek.com:9095/job/Spec/lastSuccessfulBuild/artifact/) Hope it helps, Ben On 04 Apr 2014, at 12:18, Goubier Thierry thierry.goub...@cea.fr wrote: Le 04/04/2014 12:04, MartinW a écrit : Goubier Thierry wrote By the way, any chance of having your code as an example for Spec? I went through the spec documentation and I couldn't see anything similar, and, from our difficulties to get that to work, I would guess a bit of work on Spec drag and drop support could be a good thing. I just start investigating my ui possibilities with pharo for a new application. The code examples in this thread are all there is at the moment. Ok. Still, they offer a good working base for a specific use case. Goubier Thierry wrote Are there other possibilities if i do not use Spec? Yes. Drag and drop code in Morphic is fairly similar. The Morphic code for opening windows is certainly longer, however. Yes, there are more possibilities if i do it in pure Mophic/Polymorph? — or possibilites are quite similar? :) You get better control over what drag and drop means (including the ability to control per-item if you will accept the target, or what to carry when the drag starts), but the framework takes time to get into. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-users] Drag and drop items between list views
Ben On 07 Apr 2014, at 12:17, MartinW w...@fastmail.fm wrote: Benjamin Van Ryseghem (Pharo) wrote Out of this thread, I have made this post: http://spec.st/docs/drag_n_drop/ With a small change in the Spec code base (to not sort by default, but only when a sorting block is specified), it gives an example of how to do what you want :) Cool. Thank you. Still the fact that the passenger does only know the object's string representation is a problem. Because in a real application i would not display strings and integers in the lists, but my domain objects. And already with this example it does not work: you convert the string to an integer when it leaves list1 - but of course a user might drag it back from list2 to list1 - and here you can no longer convert it as you do not know if the dragged object is a string or an integer… Why does the passenger only know an object's string representation? Can this be changed? This should be changed, but this is to be fixed in Morphic, and since it’s not breaking anything in Pharo (so far), it will be changed in early 4.0 Ben -- View this message in context: http://forum.world.st/Drag-and-drop-items-between-list-views-tp4752285p4753118.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Few questions about Spec (instance specific layout and skinning)
If you need it the other way around, then instead of calling it in the layout,
there is a method on adapter named #buildWidget (or something close)
which is the perfect place for this :)
Ben
On 04 Apr 2014, at 01:53, Thomas Bany mun.sys...@gmail.com wrote:
Okey so I looked deeper into the interpreter and found that the receiver of
the next call is the returned value of the previous. I'm pretty sure it
explains the infinite loop I was encountering.
It also made it problematic to register the morph to the anouncement of the
adapter, since #addDependent: is send with a morph to the model and I needed
the other way arround.
Adding #beDependentTo: somewhere in the class hierarchy of SimpleSwitchMorph
make it work but I'm not sure I should do that.
2014-04-03 20:37 GMT+02:00 Thomas Bany mun.sys...@gmail.com:
Hum, I was pondering the problem at home and started from scratch. I don't
have the issue anymore ...
2014-04-03 18:40 GMT+02:00 Thomas Bany mun.sys...@gmail.com:
Hey,
I have a quick question. I'm trying to build an adapter (called
MorphicSwitchAdapter) and a model for SimpleSwitchMorp. I based my layout on
the ones in existing adapter (namely MorphicButtonAdapter).
And I get stuck in an infinite loop during the interpretation of the layout
of the adapter.
The first lines are:
^ {#SimpleSwitchMorph.
#onColor:. #(model onColor).
#offColor:. #(model #offColor)
etc...
At some point, it tries to interpret #(#model #offColor)) and a few step
latter, it comes back to step one and tries to interpret
#(#MorphicSwitchAdapter #adapt: #model).
I tried this alternative {#model. #onColor} (though this one is equivalent to
me) and this one #model. #onColor. but to no avail.
I have a feeling that the problem stems from the fact that
PluggableButtonMorph seems to allready be an adapter which take a model while
SimpleSwitchMorp does not.
Could you throw some light as to why the interpretation fails ?
Again, thanks for your help !
Thomas.
Re: [Pharo-users] Drag and drop items between list views
Why not, but this will not solve the issue :) I will probably fix that in the train today (5h long trip to Bordeaux ^^) . The issue is that the items are sorted by default, which means that the list is populated with a copy of the items provided. Maybe it should not :) Then for the convenient methods, I am not that sure :P But maybe it’s a good use case for traits :P Ben On 04 Apr 2014, at 09:19, Goubier Thierry thierry.goub...@cea.fr wrote: Hi Ben, I think that hard-linking the collections inside the drop block isn't working in that case, so you have to write that without any reference to collection1 and collection2 :) But, since you're here: why don't I have an API to add or remove items from the ListModel instance? If I was working in VisualWorks, I would have used one of the model subclasses for collections and I would have used its API for adding or removing items... Here writing code like: list1 acceptDropBlock: [ :transfer :event :source :receiver :index | | c1 c2 l1 l2 | l1 := source model model. l2 := transfer source model model. transfer passenger do: [ :e | l1 insert: e first before: index. l2 remove: e first ] ]. i.e. have the ListModel instance behave as a collection for a subset of the usual collection api. Thierry Le 04/04/2014 00:40, Benjamin Van Ryseghem a écrit : here is a hackish solution: collection1 := #(1 2 3 4 5) asOrderedCollection. collection2 := #($a $b $c $d $e) asOrderedCollection. list1 := ListModel new. list1 items: collection1. list1 dragEnabled: true. list1 dropEnabled: true. list1 acceptDropBlock: [ :transfer :event :source :receiver :index | | c1 c2 l1 l2 | l1 := source model model. c1 := l1 listItems. l2 := transfer source model model. c2 := l2 listItems. transfer passenger do: [ :e | c1 insert: e first before: index. c2 remove: e first ]. l1 items: c1. collection1 removeAll; addAll: c1. l2 items: c2. collection2 removeAll; addAll: c2. ]. list1 openWithSpec. list2 := ListModel new. list2 items: collection2. list2 dragEnabled: true. list2 dropEnabled: true. list2 acceptDropBlock: [ :transfer :event :source :receiver :index | self halt ]. ^ list2 openWithSpec. The problem here is that by default, the list items are sorted, setting the listItems with a copy. Maybe it would be better to actually do not sort until one sets a real sortingBlock. Ben 2014-04-03 22:55 GMT+02:00 MartinW w...@fastmail.fm mailto:w...@fastmail.fm: Goubier Thierry wrote Another approach, that I would use, is to put more complex objects inside the lists. Thoses objects would know how to get added / removed from their respective collections, and then I would propagate collection changes to the ListModel instances. That sounded promising. I made a Collectible class. It's instances know how to add themselves to a collection (i'm not sure if that's a good idea, but as experiment..) The problem is, i never get to these objects in my acceptDropBlock. In list1 acceptDropBlock: [ :transfer :event :source :receiver :index | transfer passenger do: [:element | element addSelfToCollection: collection1] ]. the element is only a ByteString - the name of my Collectible object. :( Are there other possibilities if i do not use Spec? -- View this message in context: http://forum.world.st/Drag-and-drop-items-between-list-views-tp4752285p4752625.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-users] Few questions about Spec (instance specific layout and skinning)
On 03 Apr 2014, at 12:50, Thomas Bany mun.sys...@gmail.com wrote:
I will defenitly look into that. The rebuild may be missleading, is it also
called at first building ?
That’s your own ,method, call it as/when you want
Well, I can't even manage to tweak it through hardcoding stuff on the adapter
:p
Yes, it’s hardcoded in the morph themselves
Do you think it would be hard to use a SimpleSwitchMorph ? As I understood,
there is #asSpecAdapter that permis to plug pretty much everything ? Plus,
making a specific adapter seems doable (I mean for a rookie like me).
That’s definitely a solution :)
Well, I definitely have a variable number of buttons, depending on the model
instance. Actualy, I want my model to be a matrix of toggle to specify a
mask. I create instance with:
MaskModel class#maxIndex: anInteger
^(self basicNew)
maxIndex: anInteger;
initialize;
yourself
and instantiate a collection of buttons in #initializeWidgets.
It doesn't change much after that so a DynamicComposableModel didn't seem
usefull. But I only though that because I never used it. I will give it a try.
In DynamicComposableModel, when you instantiate a model using
#instantiateModels:
it simulates accessors for you.
By example, if you do
1 to: 120 random do: [ :i |
self instantiateModels: {
(‘b’, i asString) asSymbol . #ButtonModel
}
Then your layout can be
^ SpecLayout composed
add: #b1;
add: #b2;
etc
Ben
Re: [Pharo-users] Drag and drop items between list views
here is a hackish solution: collection1 := #(1 2 3 4 5) asOrderedCollection. collection2 := #($a $b $c $d $e) asOrderedCollection. list1 := ListModel new. list1 items: collection1. list1 dragEnabled: true. list1 dropEnabled: true. list1 acceptDropBlock: [ :transfer :event :source :receiver :index | | c1 c2 l1 l2 | l1 := source model model. c1 := l1 listItems. l2 := transfer source model model. c2 := l2 listItems. transfer passenger do: [ :e | c1 insert: e first before: index. c2 remove: e first ]. l1 items: c1. collection1 removeAll; addAll: c1. l2 items: c2. collection2 removeAll; addAll: c2. ]. list1 openWithSpec. list2 := ListModel new. list2 items: collection2. list2 dragEnabled: true. list2 dropEnabled: true. list2 acceptDropBlock: [ :transfer :event :source :receiver :index | self halt ]. ^ list2 openWithSpec. The problem here is that by default, the list items are sorted, setting the listItems with a copy. Maybe it would be better to actually do not sort until one sets a real sortingBlock. Ben 2014-04-03 22:55 GMT+02:00 MartinW w...@fastmail.fm: Goubier Thierry wrote Another approach, that I would use, is to put more complex objects inside the lists. Thoses objects would know how to get added / removed from their respective collections, and then I would propagate collection changes to the ListModel instances. That sounded promising. I made a Collectible class. It's instances know how to add themselves to a collection (i'm not sure if that's a good idea, but as experiment..) The problem is, i never get to these objects in my acceptDropBlock. In list1 acceptDropBlock: [ :transfer :event :source :receiver :index | transfer passenger do: [:element | element addSelfToCollection: collection1] ]. the element is only a ByteString - the name of my Collectible object. :( Are there other possibilities if i do not use Spec? -- View this message in context: http://forum.world.st/Drag-and-drop-items-between-list-views-tp4752285p4752625.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Few questions about Spec (instance specific layout and skinning)
On 02 Apr 2014, at 12:10, Thomas Bany mun.sys...@gmail.com wrote:
Hi !
First, I apologyse for the wall of text.
I'm trying my hands at Spec and I have few questions:
How can I implement an instance-dependent layout ?
The usual solution is to have a method looking like this on instance side
rebuildMyLayout
| layout |
layout := self buildStateDependentLayout.
self buildWithLayout: layout.
buildStateDependentLayout
^ SpecLayout composed
etc...
Regarding the layout method lookup, the documentation states that it starts
on instance side, which allows a UI to have a more specific layout depending
on the state of the instance
I tried to simply put a layout in an instance method with the spec:
#default pragma. But not only was it not retrieved by
ComposableModel#defaultSpecSelector but ComposableModel#retrieveSpec: will
send the selector on the class anyway.
What I ended up doing was overiding #openWithSpec (which worked) but I'm
pretty sure that my model is not composable at all.
Indeed, overriding openWithSpec may be a bit hackish, but should still work :)
Another solution could be to override defaultSpecSelector and/or retrieveSpec:
Is it possible to change the skin of the basic widget ?
The hooks are basically here, but the Morphs have an issue with this.
The “skin” of a Morph is supposed to be immutable, hence it takes back its
default value at each refresh :S
I would like to implement some sort of toggle button by changing the color of
ButtonModel and so far, I failed. I was not able to trace my color change up
to the PluggableButtonMorph because it seems to use anoucement and I'm a
Smalltalk rookie.
I tried however to send #color: directly to the morph which does nothing: the
#changed method rolls it back to its previous value. So I may be doing
something wrong but it doesn't feel like the issue comes from Spec. Any clue ?
So far, it will not work, sorry :(
On a side note, I tried to send an argument to the selector that retrieve a
widget in the layout method.
And I came up with this :
layout add: {#buttonAt: . 1}; add: {#buttonAt: . 2}; add: {#buttonAt: . 3}
Is it how it's done ?
That’s a solution.
Then if you have a fixed number of buttons, you could also implement a getter
for each.
If you have an undetermined number of button, then DynamicComposableModel is
for you.
Thanks in advance !
You are welcome :)
Ben
[Pharo-users] New website about Spec - http://spec.st
Hi guys :) I am glad to announce (even if Philippe already let the cat out :P) a website dedicated to Spec: http://spec.st. You can find a quick introduction, documentation (mainly what is now in the Pharo For The Enterprise book), and a news feed where I will explain the API changes, the news widgets introduce etc. The website contents can be found here (https://github.com/spec-framework/website) so if you want to contribute you are welcome :) Ben PS: I would like to thank Johan Fabry who helped me a lot writing the documentation, Sean P. DeNigris who fixed my english a couple of times and Nicolas Petton who helped me on the website look and feel
Re: [Pharo-users] [Pharo-dev] New website about Spec - http://spec.st
On 28 Mar 2014, at 14:43, Pharo4Stef pharo4s...@free.fr wrote: What is the best github repo to edit the chapter? https://github.com/spec-framework/documentation, since I would like to gather as much as possible all the things related to spec at only one place :) Ben
Re: [Pharo-users] Java this against our thisContext
Within an instance method or a constructor, this is a reference to the current object — the object whose method or constructor is being called. You can refer to any member of the current object from within an instance method or a constructor by using this. from: http://docs.oracle.com/javase/tutorial/java/javaOO/thiskey.html thisContext in smalltalk points to the execution context of the method being currently evaluated. So definitely this and self are the “same” (as long as we do not talk about inner classes) thisContext does not exist in Java AFAIK Ben On 25 Mar 2014, at 11:27, Sergi Reyner sergi.rey...@gmail.com wrote: Hi everyone, I had a pretty heated IRC debate yesterday about how Smalltalk´s reflection facilities are superior to those of Java, in the sense that they operate at a higher level (I started it pasting one of those crazy snippets that got posted to the list xD). It somehow slowly degenerated into someone trying to convince me that Java's this operator is equivalent to thisContext, instead of self. My intuition says that´s wrong, but I´d very much like someone familiar with both to offer an explanation to this poor unenlightened person :D Cheers, Sergi
Re: [Pharo-users] [ANN] BabyMock 2
It looks even cooler than before :) Ben On 11 Mar 2014, at 12:30, Attila Magyar m.magy...@gmail.com wrote: I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec question
Thanks for the pointer :) Why do you subclass TreeModel instead of using one? Could you add an example and a screenshot so we can see how it looks :) Thanks, Ben On 03 Mar 2014, at 17:15, Glenn Cavarlé gl...@cavarle.fr wrote: Hi Benjamin and Hernán, I found few time to make a little example of ListView (extend TreeModel). I hosted it in my wiki : ListViewModel Example http://ijintek.fr/wiki/doku.php?id=spec_examples#listview_example The only specific point it's to well define the displayBlock block an that's all. As Benjamin said previously, it was quite easy to do that with TreeModel. Thanks Benjamin ;-) Regards, - Glenn Cavarlé -- View this message in context: http://forum.world.st/Spec-question-tp4741608p4747490.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec question
On 01 Mar 2014, at 06:18, Hernán Morales Durand hernan.mora...@gmail.com wrote: Did you have progress with that ListView in Spec? Anything to check in the repo? You can experiment a bit based on this script[1] using the latest Spec code. Ben [1] https://gist.github.com/BenjaminVanRyseghem/9306328
Re: [Pharo-users] Spec website: nice!
Because I did not knew about it until yesterday :) I will have a look next week :P (or if you want to submit a PR before LOL) Ben On 28 Feb 2014, at 11:10, Goubier Thierry thierry.goub...@cea.fr wrote: Yes, this is cool :) Nice work. Benjamin, why don't you do a ConfigurationOfSpec with an url of 'github://SpecForPharo/spec:master' ? Thierry Le 28/02/2014 10:59, p...@highoctane.be a écrit : Didn't knew about it and came across by looking at the GitHub project for Spec. http://spec.st/ Phil -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-users] Spec website: nice!
You blew up my surprise :) It is still work in progress that’s why I did not announce it before (you know, to not announce something before it’s finished :P) Ben On 28 Feb 2014, at 10:59, p...@highoctane.be wrote: Didn't knew about it and came across by looking at the GitHub project for Spec. http://spec.st/ Phil
Re: [Pharo-users] Spec website: nice!
On 28 Feb 2014, at 11:34, Goubier Thierry thierry.goub...@cea.fr wrote: Le 28/02/2014 11:26, Benjamin a écrit : Because I did not knew about it until yesterday :) Took me a while to understand that too :) Found the code when hacking support for gitfiletree in Metacello. I will have a look next week :P (or if you want to submit a PR before LOL) Hum, maybe over the week-end then. By the way, your link to github is broken :) Yes I renamed the association :) That’s one of the reason I did not publicly announce it… Ben Thierry Ben On 28 Feb 2014, at 11:10, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Yes, this is cool :) Nice work. Benjamin, why don't you do a ConfigurationOfSpec with an url of 'github://SpecForPharo/spec:master' ? Thierry Le 28/02/2014 10:59, p...@highoctane.be mailto:p...@highoctane.be a écrit : Didn't knew about it and came across by looking at the GitHub project for Spec. http://spec.st/ Phil -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-users] Spec website: nice!
Yes, there is a “thanks” page missing. Again, the website is not ready for public :) Ben On 28 Feb 2014, at 13:05, olivier auverlot olivier.auver...@gmail.com wrote: Hi Benjamin It's very cool ! The website and the documentation are very pleasant and well presented. Perhaps you could add links to the Pharo web site and the RMoD team ? Olivier ;-) 2014-02-28 11:34 GMT+01:00 Goubier Thierry thierry.goub...@cea.fr: Le 28/02/2014 11:26, Benjamin a écrit : Because I did not knew about it until yesterday :) Took me a while to understand that too :) Found the code when hacking support for gitfiletree in Metacello. I will have a look next week :P (or if you want to submit a PR before LOL) Hum, maybe over the week-end then. By the way, your link to github is broken :) Thierry Ben On 28 Feb 2014, at 11:10, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Yes, this is cool :) Nice work. Benjamin, why don't you do a ConfigurationOfSpec with an url of 'github://SpecForPharo/spec:master' ? Thierry Le 28/02/2014 10:59, p...@highoctane.be mailto:p...@highoctane.be a écrit : Didn't knew about it and came across by looking at the GitHub project for Spec. http://spec.st/ Phil -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-users] Spec website: nice!
On 28 Feb 2014, at 13:40, kilon alios kilon.al...@gmail.com wrote: definitely a very beautiful and well designed website. Well done Benjamin. Looks very professional yet it has a personal touch. I love it. Thank you :) Talking about websites I am curious, is there a plan to bring Spec to Javascript side , in particular , Amber ? We proposed it as a GSoC project. But as you know ESUG was not selected as partner. With Nicolas we are discussing since a while about how to move Spec on Amber. The battle plan is quite set up :) Now, we just need man power (as usual) I have seen that Amber has it as a goal, but I was curious how much of a serious goal it is. I think it would be very cool if Spec could leverage HTML/CSS/JS GUI wise. Nicolas is now developing a widget framework for Amber (Moka). The goal is to finish that, and then to plug Spec on top of it. We would like to have it for Amber 1.0 (but we do not know when it would be :P ) Ben On Fri, Feb 28, 2014 at 2:19 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Yes, there is a “thanks” page missing. Again, the website is not ready for public :) Ben On 28 Feb 2014, at 13:05, olivier auverlot olivier.auver...@gmail.com wrote: Hi Benjamin It's very cool ! The website and the documentation are very pleasant and well presented. Perhaps you could add links to the Pharo web site and the RMoD team ? Olivier ;-) 2014-02-28 11:34 GMT+01:00 Goubier Thierry thierry.goub...@cea.fr: Le 28/02/2014 11:26, Benjamin a écrit : Because I did not knew about it until yesterday :) Took me a while to understand that too :) Found the code when hacking support for gitfiletree in Metacello. I will have a look next week :P (or if you want to submit a PR before LOL) Hum, maybe over the week-end then. By the way, your link to github is broken :) Thierry Ben On 28 Feb 2014, at 11:10, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr wrote: Yes, this is cool :) Nice work. Benjamin, why don't you do a ConfigurationOfSpec with an url of 'github://SpecForPharo/spec:master' ? Thierry Le 28/02/2014 10:59, p...@highoctane.be mailto:p...@highoctane.be a écrit : Didn't knew about it and came across by looking at the GitHub project for Spec. http://spec.st/ Phil -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-users] Spec website: nice!
I would love too :) But as always it takes time. I try to do my best to offer an easy to read yet useful documentation. Let’s hope we can make it :) Ben On 28 Feb 2014, at 19:54, kmo vox...@gmail.com wrote: This is really good and very well done and can only get better over time. I'd like to see a complete API and description of every Spec Model added to the site and there needs to be multiple examples so that the whole range of widgets and interface types are shown. Brilliant start, though. -- View this message in context: http://forum.world.st/Spec-website-nice-tp4746941p4747048.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec and an application menu
I do agree with you all :) The things is many people ask for more things into Spec, but at the end, I am still the only one implementing them :) And as you can imagine, my time is not infinite :P I will end up proposing a kickstarted project I think :P Ben On 18 Feb 2014, at 09:36, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 18/02/2014 09:26, Goubier Thierry a écrit : Now I want to try something: populate the menu bar with all possible menu/shortcuts commands defined in my app (i.e. tree node contextual menu, code pane contextual menu, smart-suggestions type commands) to ensure discoverability, in as few lines as possible. I guess it should be a mission for Spec. For DrGeo, I have to hand write it and it is no a few lines. Not to mention I did not set up the keyboard short cut. -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] TextModel and TextInputFieldModel font-size bug?
I think it’s time to open a bug entry :) Ben On 18 Feb 2014, at 03:18, Hernán Morales Durand hernan.mora...@gmail.com wrote: I confirm this issue using a vanilla Pharo 3. PluggableTextFieldMorph new openInWindow If you comment last line here it works PluggableTextFieldMorphinitialize textMorphClass := TextMorphForFieldView. super initialize. self beDecrypted which makes me think. Why #beDecrypted? Are text morphs encrypted by default? If not we are wasting cycles there. To me it sounds like you should decrypt when something was encrypted, not just in case. However that does not resolve the issue with TextInputFieldModel. 2014-02-16 10:55 GMT-03:00 kmo vox...@gmail.com: When I create an interface in Spec with TextModel or TextInputFieldModel, the font-size is tiny. Same behaviour in both Windows and Linux. Is this a bug or have I missed something important? http://forum.world.st/file/n4744094/SmallFont.png -- View this message in context: http://forum.world.st/TextModel-and-TextInputFieldModel-font-size-bug-tp4744094.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec and an application menu
Spec provides today a new missing feature: a menu toolbar.As recently suggested in the mailing list, a menu toolbar is often a requirement to build an application.In order to provide an easy way to add a menu toolbar, Spec reuse **MenuModel** to generate the toolbar entries.So now, a **MenuModel** can be used in two cases: to define a toolbar, or to define a contextual menu.An example can be opened via ApplicationWithToolbar new openWithSpec Ben
Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished
Thank you for your review :) I have to agree with you and to answer briefly, the main problems with documentation is: - it takes time (*a lot* to me since I am more a code than a writer :P) - things evolve (that can be managed though) I will be super happy to have a more complete documentation I spend(t) time on it (and Johan too, thank you very much again :) ). Now I will be even happier to review any pull request ;) Ben On 16 Feb 2014, at 13:34, kmo vox...@gmail.com wrote: The Spec documentation is very good /as far as it goes/. As a native speaker, I would say the English is excellent, though the tone is rather dry and technical. Generally, I think it is well written and very helpful. That's not the issue. The real problem is that this documentation is no more than an overview. It is not written from a /How To/ perspective. The result is that it offers little help to anyone who wants to actually create a user interface with Spec. Here are some obvious questions that might occur to anyone starting to use Spec. None of them are answered in the current documentation. How do use Spec to write an application that fills the pharo window? (There is no mention of openWorldWithSpec in the document). How do I write an application with a main menu at the top, a toolbar under it, and a status bar at the bottom? How to I create, use and close, non-modal windows in my application? How do I write a modal dialog, ask for complex information, and get it back? (There is a modal dialog example in the document under Prototyping a UI but nothing explicit). How do I use a SliderModel, RadioButtonModel etcetera? How do I use all those cool Morphs I've found - PianoKeyboardMorph, LEDMorph etcetera - with Spec? Surely I don't have to write my own Morphic Adapter for each one? How do I migrate my Morphic application to Spec? To my mind, this document is only the beginning. It doesn't even have a list of the available Spec models and their APIs - even the original Spec Report had a table of these. The approach seems to be - here's a general idea of how it works - read the source if you actually want to do anything. Well, even an idiot like me can perhaps work out how to use a LabelModel, but TreeModel,say, with its TreeColumns and TreeNodes is not so obvious and it needs trial and error to find out how it all fits together (not helped by the complete abscebnce of helpful class comments). We don't need tail and error. We need documentation. Finally, can we please stop using class browsers as examples? I know that it is easy (and cool) to use reflection to get lists of classes, protocols and methods but this only adds to the impression that the smalltalk community is self-absorbed and narcissistic. If you want to attract business developers then use examples that relate to the real world, not to the pharo environment itself. Why not a database example or a paint application example? No one wants to write a class browser - that's already available! Perhaps I should stop before this becomes filed under /Why is smalltalk/pharo so unpopular./ To sum up, this documentation is a good start - but that's all it is. -- View this message in context: http://forum.world.st/ANN-Spec-documentation-in-PFTE-book-finished-tp4743035p4744054.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished
Any questions are welcome :) Ben On 16 Feb 2014, at 14:19, kmo vox...@gmail.com wrote: I would be happy to write some Spec documentation - when I start to understand it better. I've gained some idea of how the TreeModel works so perhaps i could do something on that and you could roll it into the Spec documentation somewhere. Just a suggestion. Meanwhile expect a barrage of questions about Spec on this mailing list as I start to look at Spec more closely. -- View this message in context: http://forum.world.st/ANN-Spec-documentation-in-PFTE-book-finished-tp4743035p4744071.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec model attributes - is there a strategy
On 16 Feb 2014, at 14:47, kmo vox...@gmail.com wrote: Is there some deep philosophical reason behind this that I don't understand? The reason is simply that it was not needed until now, so not yet implemented :) Spec does not give you control over fonts and colours. One should be able to specify a spec model color. Now, I am not sure the adapters take this attribute into account. But if you want to write an application you might well want a particular Look and Feel. I do agree :) Ben
Re: [Pharo-users] TextModel and TextInputFieldModel font-size bug?
Did you tried with morph? Because for me I would say it happens more at a Morphic level Ben On 16 Feb 2014, at 14:55, kmo vox...@gmail.com wrote: When I create an interface in Spec with TextModel or TextInputFieldModel, the font-size is tiny. Same behaviour in both Windows and Linux. Is this a bug or have I missed something important? http://forum.world.st/file/n4744094/SmallFont.png -- View this message in context: http://forum.world.st/TextModel-and-TextInputFieldModel-font-size-bug-tp4744094.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec and Morphs
Indeed :) Ben On 16 Feb 2014, at 15:16, kmo vox...@gmail.com wrote: Great. Just what I wanted. Many thanks. But consider putting it in the spec documentation - I think it's an important thing to know. -- View this message in context: http://forum.world.st/Spec-and-Morphs-tp4744084p4744109.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec and an application menu
There is no such a morph existing (yet). You can do something based on button invoking popup menu (like here: https://github.com/BenjaminVanRyseghem/Triton/blob/master/Screenshots/Screenshot3.png) If you want some snippet based on this work around, just ask Ben On 16 Feb 2014, at 20:11, kmo vox...@gmail.com wrote: Can someone provide example Spec code to place a menubar at the top of a window? I've been struggling with MenuModels and MenuGroups etcetera but I get something more like a pop-up menu than the typical standard main menu of an application. Any help much appreciated. -- View this message in context: http://forum.world.st/Spec-and-an-application-menu-tp4744164.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec and an application menu
I think a Spec model could be done to provide this feature About the integration in 3.0, one may argue it’s not present since years, nobody complained so :P Ben On 16 Feb 2014, at 23:33, b...@openinworld.com wrote: Benjamin wrote: There is no such a morph existing (yet). You can do something based on button invoking popup menu (like here: https://github.com/BenjaminVanRyseghem/Triton/blob/master/Screenshots/Screenshot3.png) If you want some snippet based on this work around, just ask Ben On 16 Feb 2014, at 20:11, kmo vox...@gmail.com wrote: Can someone provide example Spec code to place a menubar at the top of a window? I've been struggling with MenuModels and MenuGroups etcetera but I get something more like a pop-up menu than the typical standard main menu of an application. Any help much appreciated. -- View this message in context: http://forum.world.st/Spec-and-an-application-menu-tp4744164.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. I've not had occasion to need it yet, but that seems like a critical omission for developers of traditional business software. Could almost be considered a bug in requirements :) Perhaps something should be included in Pharo 3 - in spite of the Pharo 3 feature freeze? cheers -ben
Re: [Pharo-users] Stupid Question
sm delete ? Ben On 08 Feb 2014, at 18:12, Bob Williams rwilliam...@cox.net wrote: I am exploring Morphs and I tried the following code: |sm ws| ws := WideString new: 5. ws wordAt: 1 put: 16r2264. ws wordAt: 2 put: 16r22C5. ws wordAt: 3 put: 16r2211. ws wordAt: 4 put: 16r2219. ws wordAt: 5 put: 16r221A. sm := SimpleSwitchMorph new. sm label: ws font: (LogicalFont familyName: 'Cambria Math' pointSize: 15). sm openInWorld. Now in the upper left corner of the World screen I have a button that shows the math symbols, LTE, dot, Summation, large-dot and SQRT, and will change backcolor from gray to light-red. Exactly what I wanted; however, how do I get rid of the morph? The class documentation is full of examples of this kind so there must be a way to clean up the World as It persists through a quit and save and then open. Thanks.
Re: [Pharo-users] Spec question
I think the widget to look at is TreeModel :) Do you have an image showing what you would like? Ben On 05 Feb 2014, at 00:58, Glenn Cavarlé gl...@cavarle.fr wrote: Hi all, i'm new (first post) and my english is very poor so please don't blame me :). I would like to use Spec for display a collection of domain objects and i would like to specify the layout which apply to each items, not just display a String or a Text like ListModeldisplayBlock: but a more complexe layout with rows, columns and images within (for example). To illustrate, an equivalent would be the component ListView in Android. I turn to you to know if it's possible to do that with Spec. Thanks, Regards, Glenn - Glenn Cavarlé -- View this message in context: http://forum.world.st/Spec-question-tp4741608.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] SourceCity on Delphi code
I saw one couple of days ago, it was quite cool :) I cc Milton so he can tell you more :) Ben On 28 Jan 2014, at 11:08, Esteban Lorenzano esteba...@gmail.com wrote: it is not possible to show the roassal3d version (no idea what is the status of it)? Esteban On 28 Jan 2014, at 14:36, Stephan Eggermont step...@stack.nl wrote: Works in Pharo 2.0, but is not loadable in Pharo 3. I’d love to be able to show it in Moose 5.0 this saturday, instead of with a fuel dump of the model. Anyone know what needs to be done? Stephan PastedGraphic-1.png
Re: [Pharo-users] Unwind error during termination
cmd+w Ben On 07 Jan 2014, at 15:37, Esteban A. Maringolo emaring...@gmail.com wrote: I have this highlander error message popping over. Any suggestion on how to kill it? Esteban A. Maringolo unwindProcess.png
Re: [Pharo-users] Help us to have really cool Pharo 3 release!
nice metaphor! It made me think about maradona :) So from argentinian it means that we can also play football with our hands o:) And tons of cocaine :P Ben
Re: [Pharo-users] Number slider
Not that I know. But it’s pretty easy to do :) Ben On 03 Jan 2014, at 15:01, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Hello, Do we have number slider Morph like this one: http://diveintohtml5.info/i/input-type-number-opera.png Thanks Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Pharo private develoment
Smalltalkhub private project or bitbucket And I deployed my own Jenkins. It’s as complicated as `sudo apt-get install jenkins` Ben On 01 Jan 2014, at 19:26, Esteban A. Maringolo emaring...@gmail.com wrote: Pharo as a community has support to use its CI server, among other goodies such as SmalltalkHub. But what if your code is not public and you want to have a central repository and continuous builds? Has anybody ever wrote a guide to develop with Pharo in the context of private development? So far I managed to work with a file based repo and a set of workspaces to create a new working image or to prepare it for deployment. But I want to automate it as much as I can. Regards! Esteban A. Maringolo
[Pharo-users] [Pharo-dev] [Pharo Trick: #0007] - Write UI prototype in a workspace
--- [Pharo Trick: #0007] - Write UI prototype in a workspace --- Works in: Pharo 2.0, 3.0, ... --- In Morphic, there is no way to quickly prototype a UI. But in Spec there is a Dynamic class supporting this, so one can try different things directly from a Workspace An example: m := DynamicComposableModel new. m instantiateModels: #( button ButtonModel list ListModel). m list items: #(1 2 3 4 5). m button label: 'Plip'; action: [ self halt ]. m openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #list ; add: #button height: 26 ]; yourself). Ben
Re: [Pharo-users] [launcher] fixed layout of tollbar buttons
I was referencing to the LaTeX command \hfill http://en.wikibooks.org/wiki/TeX/hfill Ben On 12 Dec 2013, at 14:48, b...@openinworld.com wrote: Thanks Ben. But why is it required? I think I am missing some basic info how layouts work on the Morph side, and the few references to #hFill in the image don't tell me much. btw, adding a method #hFill would make it look like less of a hack. cheers -ben Benjamin wrote: The empty column is used as a \hFill :) Ben On 12 Dec 2013, at 13:57, b...@openinworld.com wrote: Hi Damien, Benjamin.V.R. I see in PharoLauncher-Spec-DamienCassou.17 that the layout of the toolbar buttons is fixed, which is really great. However in trying to learn from that for future reference, seeing it relies on an empty column being added seems like a hack to workaround some issue with Spec. Should that be logged as a bug? Or is there some greater architectural background for this that I am missing? PhLCommandTooldbardynamicLayout (newer) Create a spec layout with 1 row, and as many columns as there are command classes ^ SpecLayout composed newRow: [ :r | r newColumn: [ :col | ]. FIX self commandClasses do: [ :commandClass | r add: commandClass specId width: self class toolbarHeight ] ] I tried digging into Spec to look at this myself, and my naive intuition felt it was something to do with initialization of LayoutFrames, but that was my first exposure to LayoutFrame and I quickly got lost. However I was reminded of Igor commenting i only know that if you using proportional layout, then if you want submorphs to be laid down properly, you must use addMorph:fullFrame: instead of just addMorph: [1] I tried this with a few hacks, but tit was really shooting in the dark and unsuccessful. [1] https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg08838.html cheers -ben PharoLauncher-fixed-button-layout.png
Re: [Pharo-users] openFullscreen a WindowModel
then (note it’s a hack) WindowModel#openFullscreen self widget ifNotNil: [ :w | w openFullScreen ] Ben On 05 Dec 2013, at 10:59, Picci Pharo prova...@hotmail.it wrote: The Class MorphicWindowAdapter doesn't exist in Pharo 2.0 From: benjamin.vanryseghem.ph...@gmail.com Date: Wed, 4 Dec 2013 11:26:54 +0100 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] openFullscreen a WindowModel Add: WindowModel#openFullscreen self changed: #openFullscreen with: #() MorphicWindowAdapter#openFullscreen self widgetDo: [ :w | w openFullscreen ] And tada Ben On 04 Dec 2013, at 11:13, Picci Pharo prova...@hotmail.it wrote: Hi Guys! One simple question: how can i open fullscreen a WindowModel? As you know, the StandardWindow has got the message openFullscreen, but it obviously doesn't work for the WindowModel. Any suggestion? Ciao! Paolo
Re: [Pharo-users] openFullscreen a WindowModel
or openFullscreen, The one known by SystemWindow Ben On 05 Dec 2013, at 11:11, Picci Pharo prova...@hotmail.it wrote: openFullscreen
Re: [Pharo-users] openFullscreen a WindowModel
No I am saying that self widget ifNotNil: [ :w | w openFullScreen ] w in here is a StandardWindow. Ben On 05 Dec 2013, at 11:18, Picci Pharo prova...@hotmail.it wrote: Are you telling me that i can copy the openFullscreen of StandardWindow and put it into the class WindowModel? Paolo From: benjamin.vanryseghem.ph...@gmail.com Date: Thu, 5 Dec 2013 11:13:35 +0100 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] openFullscreen a WindowModel or openFullscreen, The one known by SystemWindow Ben On 05 Dec 2013, at 11:11, Picci Pharo prova...@hotmail.it wrote: openFullscreen
Re: [Pharo-users] openFullscreen a WindowModel
Sorry for not knowing the StandardWindow API by heart (yet) :P Ben On 05 Dec 2013, at 11:28, Picci Pharo prova...@hotmail.it wrote: It Works But the capital S is your mistake :-) Thanks Ben, hope to speak soon with you and Steph here in Brescia for the next ESUG. Paolo From: benjamin.vanryseghem.ph...@gmail.com Date: Thu, 5 Dec 2013 11:21:40 +0100 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] openFullscreen a WindowModel No I am saying that self widget ifNotNil: [ :w | w openFullScreen ] w in here is a StandardWindow. Ben On 05 Dec 2013, at 11:18, Picci Pharo prova...@hotmail.it wrote: Are you telling me that i can copy the openFullscreen of StandardWindow and put it into the class WindowModel? Paolo From: benjamin.vanryseghem.ph...@gmail.com Date: Thu, 5 Dec 2013 11:13:35 +0100 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] openFullscreen a WindowModel or openFullscreen, The one known by SystemWindow Ben On 05 Dec 2013, at 11:11, Picci Pharo prova...@hotmail.it wrote: openFullscreen
Re: [Pharo-users] openFullscreen a WindowModel
Add: WindowModel#openFullscreen self changed: #openFullscreen with: #() MorphicWindowAdapter#openFullscreen self widgetDo: [ :w | w openFullscreen ] And tada Ben On 04 Dec 2013, at 11:13, Picci Pharo prova...@hotmail.it wrote: Hi Guys! One simple question: how can i open fullscreen a WindowModel? As you know, the StandardWindow has got the message openFullscreen, but it obviously doesn't work for the WindowModel. Any suggestion? Ciao! Paolo
Re: [Pharo-users] Seaside on Pharo 3.0
and it will take 40 minutes :P Ben On 02 Dec 2013, at 17:56, Esteban Lorenzano esteba...@gmail.com wrote: this should work: $ wget -O- get.pharo.org/30+vm | bash $ ./pharo ./Pharo.image config http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main ConfigurationOfSeaside3 --install=stable cheers, Esteban On Mon, Dec 2, 2013 at 5:50 PM, sminni s...@planage.com wrote: Hi Pls guide me in getting an environment of Seaside / Zinc / Pharo 3.0 up and running Regards Sanjay - --- Regards, Sanjay -- View this message in context: http://forum.world.st/Seaside-on-Pharo-3-0-tp4726765.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] reporting bugs
If you are not logged, the process should be describe on the welcome page Ben On 28 Nov 2013, at 09:19, Nicolai Hess nicolaih...@web.de wrote: What do I have to do for getting access to pharo.fogbugz.com for bug reporting? regards Nicolai
Re: [Pharo-users] reporting bugs
There is also this perm link :) http://bugs.pharo.org/issues/register Ben On 28 Nov 2013, at 09:45, p...@highoctane.be wrote: http://bugs.pharo.org/issues/ Register link on top: You can register to the FogBugz issue tracker here. Enjoy, --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Nov 28, 2013 at 9:19 AM, Nicolai Hess nicolaih...@web.de wrote: What do I have to do for getting access to pharo.fogbugz.com for bug reporting? regards Nicolai
Re: [Pharo-users] reporting bugs
Looks great :) Thanks for the contribution :) Ben On 28 Nov 2013, at 11:13, p...@highoctane.be wrote: Due to the somewhat unclear process, I updated the issue tracking page with some details about registration along with pictures. http://www.pharo-project.org/community/issue-tracking Tell me if you see things that aren't right. Phil On Thu, Nov 28, 2013 at 10:42 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 28 Nov 2013, at 10:28, Nicolai Hess nicolaih...@web.de wrote: Thank you all for your help. I already tried http://bugs.pharo.org/issues/register (month ago and now again),but nothing happened. I missed that part where I have to use forgot password to even get an initial password. Can you write this important part right on the initial fogbugz page. For those people who don't watch tutorial videos :-) Yes, also I couldn’t make my me.com mail to work. I hope that soon we will have normal bug tracker :) Uko 2013/11/28 Benjamin benjamin.vanryseghem.ph...@gmail.com There is also this perm link :) http://bugs.pharo.org/issues/register Ben On 28 Nov 2013, at 09:45, p...@highoctane.be wrote: http://bugs.pharo.org/issues/ Register link on top: You can register to the FogBugz issue tracker here. Enjoy, --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Nov 28, 2013 at 9:19 AM, Nicolai Hess nicolaih...@web.de wrote: What do I have to do for getting access to pharo.fogbugz.com for bug reporting? regards Nicolai
Re: [Pharo-users] Nautilus pkg-pane regression in pharo 3.0?
if it’s a leaf and you do - you jump. if it’s not a leaf, you expand Ben On 24 Nov 2013, at 10:14, Esteban Lorenzano esteba...@gmail.com wrote: Yes, I'm aware... I still do not decide if is a bug or a feature :) Honestly, the problem is the collision of functionality for - and -. And I don't know how to handle it. Suggestions? Esteban On Sun, Nov 24, 2013 at 12:59 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: That a major issue so far. It was not intended, but since the tree widget already handle arrow right by itself, I do not know if Esteban thought about this feature Ben On 23 Nov 2013, at 22:34, Lorenz Köhl lor...@quub.de wrote: Nautilus has stopped jumping to packages when the focus is in the package pane and keys are pressed (the same behaviour use from eg. osx finder) Is that a regression or intended?
Re: [Pharo-users] Writing a GUI - Where to start?
The problem is here rowPlayer add: (textPlayer at:i) ; add:#captainButton; add: (buttonStartingEleven at:i). ]. As you see, the argument of add: is a symbol, but in the first and third add, you add directly a TextInputFieldModel In addition your usage of class inst var is a bit disturbing :) Ben On 22 Nov 2013, at 11:08, prova email prova...@hotmail.it wrote: Hi Ben, here the .st file, there are some comments in italian, i hope it's not a problem. I know that Spec is the most used and it will be the standard GUI builders in the future, so i'd like to find a solution here, without changing to Morph and Polymorphic. Paolo From: benjamin.vanryseghem.ph...@gmail.com Date: Fri, 22 Nov 2013 11:04:53 +0100 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] Writing a GUI - Where to start? It seems that you return the wrong object somewhere :) Could you commit your code somewhere so I can have a look ? Ben On 22 Nov 2013, at 11:01, prova email prova...@hotmail.it wrote: I started to use Spec, i love nested layouts and so on. But i've got a little problem. I'm creating a Window with 14 TextInputFieldModel and 14 ButtonModel and, to avoid the definition of 28 different instance variables (obviously), i created two arrays which contain the ButtonModel and the TextInputFieldModel that i need. ^ SpecLayout composed newColumn: [ :columnTeam | 1 to: 14 do:[:i| columnTeam newRow: [ :rowPlayer | rowPlayer add: (textPlayer at:i) ; add:#captainButton; add: (buttonStartingEleven at:i). ]. . This is what i did in the defaultSpec of my Player class. captainButton is a RadioButton defined in self instantiateModels: in initializeWidgets, while textPlayer and buttonStartingEleven are the arrays of above. Theoretically the idea is great, while in practice it doesn't work. It give me the following message: TextInputFieldModellayoutFrame: Help me please! Paolo From: jfa...@dcc.uchile.cl Date: Wed, 20 Nov 2013 14:38:58 -0300 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] Writing a GUI - Where to start? I recommend you to go with Spec. It is the newest and designed to be the most capable. It is also the way forward, it will be the 'standard' GUI builders in the future. We know that the documentation right now is far from optimal. Ben and I will work on that in January. On Nov 20, 2013, at 1:30 PM, Mun Mun mun.sys...@gmail.com wrote: Hi everyone, Nobody mentioned Polymorphic. My understanding is that both Spec and Polymorph are built on top of Morphic. I only looked at code example and brief tutorial for both of them, but it seemed to me that Polymorph was easier to grasp: it's quite obivous in the code where and how the widgets are built. I have trouble understanding how the job is done in Spec. On the other hand, Spec seems to have a lot of users in this mailling list. To sum up this thread with many different options proposed, what would be the right path for a newbie like me ? Thanks in advance ! --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile PBE-SquadraPROVA.st
Re: [Pharo-users] Writing a GUI - Where to start?
Here is a working version based on DynamicComposableModel (a subclass dedicated to the caseswhere you have a lot, or an undefined number of sub widgets) ProvaSquadra.st Description: Binary data Ben On 22 Nov 2013, at 11:08, prova email prova...@hotmail.it wrote:Hi Ben,here the .st file, there are some comments in italian, i hope it's not a problem.I know that Spec is the most used and it will be the standard GUI builders in the future, so i'd like to find a solution here, without changing to Morph and Polymorphic.PaoloFrom:benjamin.vanryseghem.ph...@gmail.comDate: Fri, 22 Nov 2013 11:04:53 +0100To:pharo-users@lists.pharo.orgSubject: Re: [Pharo-users] Writing a GUI - Where to start?It seems that you return the wrong object somewhere :)Could you commit your code somewhere so I can have a look ?BenOn 22 Nov 2013, at 11:01, prova email prova...@hotmail.it wrote:I started to use Spec, i love nested layouts and so on. But i've got a little problem. I'm creating a Window with 14 TextInputFieldModel and 14 ButtonModel and, to avoid the definition of 28 different instance variables (obviously), i created two arrays which contain the ButtonModel and the TextInputFieldModel that i need.^ SpecLayout composed newColumn: [ :columnTeam | 1 to: 14 do:[:i|columnTeam newRow: [ :rowPlayer | rowPlayer add: (textPlayer at:i) ; add:#captainButton; add: (buttonStartingEleven at:i).]..This is what i did in the defaultSpec of my Player class. captainButton is a RadioButton defined in self instantiateModels: in initializeWidgets, while textPlayer and buttonStartingEleven are the arrays of above.Theoretically the idea is great, while in practice it doesn't work. It give me the following message:TextInputFieldModellayoutFrame:Help me please!Paolo From:jfa...@dcc.uchile.cl Date: Wed, 20 Nov 2013 14:38:58 -0300 To:pharo-users@lists.pharo.org Subject: Re: [Pharo-users] Writing a GUI - Where to start? I recommend you to go with Spec. It is the newest and designed to be the most capable. It is also the way forward, it will be the 'standard' GUI builders in the future. We know that the documentation right now is far from optimal. Ben and I will work on that in January. On Nov 20, 2013, at 1:30 PM, Mun Mun mun.sys...@gmail.com wrote: Hi everyone, Nobody mentioned Polymorphic. My understanding is that both Spec and Polymorph are built on top of Morphic. I only looked at code example and brief tutorial for both of them, but it seemed to me that Polymorph was easier to grasp: it's quite obivous in the code where and how the widgets are built. I have trouble understanding how the job is done in Spec. On the other hand, Spec seems to have a lot of users in this mailling list. To sum up this thread with many different options proposed, what would be the right path for a newbie like me ? Thanks in advance ! --- Save our in-boxes!http://emailcharter.org--- Johan Fabry -http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of ChilePBE-SquadraPROVA.st
Re: [Pharo-users] Deploying a polymorph app - two questions
On 23 Nov 2013, at 16:13, kmo vox...@gmail.com wrote: Benjamin - Many thanks. Your suggestion of World submorphs do: [:e | e delete ] was just what I needed to get rid of the taskbar. However, DisplayScreen hostWindowTitle does not work for me. I'm not using Spec but surely that should make no difference. Is it a platform bug (I'm on ubuntu 13.04) or are you using pharo 3.0? I'm on pharo 2.0 (there is no WorldModel as far as I can see). So, is DisplayScreen hostWindowTitle broken on pharo 2.0? Might be, I am on mac + Pharo 3.0 and it works. And I think that the Pharo Launcher uses this feature too and works on ubuntu. So probably a problem in 2.0, or you are using an old vm maybe Ben ken -- View this message in context: http://forum.world.st/Deploying-a-polymorph-app-two-questions-tp4724525p4724550.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] spec and double click
m := NewListModel new m doubleClickAction: [ self halt ] m openWithSpec This should work Ben On 23 Nov 2013, at 19:23, Lorenz Köhl lor...@quub.de wrote: I strongly suggest to use 30 because spec changed a lot. Doesn't seem to work either (on yesterdays 30): | m | m := ListModel new items: #(a b c). m when: #doubleClick send: #traceCr to: Transcript. m on: #doubleClick send: #traceCr to: Transcript. need doubleclick announcement? m openWithSpec Maybe there's some spec mechanism for adding the EventHandler stuff to the morphs it creates? greetings, Lo
Re: [Pharo-users] Nautilus pkg-pane regression in pharo 3.0?
That a major issue so far. It was not intended, but since the tree widget already handle arrow right by itself, I do not know if Esteban thought about this feature Ben On 23 Nov 2013, at 22:34, Lorenz Köhl lor...@quub.de wrote: Nautilus has stopped jumping to packages when the focus is in the package pane and keys are pressed (the same behaviour use from eg. osx finder) Is that a regression or intended?
Re: [Pharo-users] spec and double click
I will have a look tomorrow :) If you are in a hurry, I know such a behaviour is present in EyeInspector Ben On 24 Nov 2013, at 00:07, Lorenz Köhl lor...@quub.de wrote: On Nov 23, 2013, at 7:37 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: m := NewListModel new m doubleClickAction: [ self halt ] m openWithSpec your code and the following (double clicking the list items) doesn't work for me in Pharo3.0 Latest update: #30591 m := NewListModel new items: #(a b c). m doubleClickAction: [ Transcript traceCr: 'foo' ]. m openWithSpec
Re: [Pharo-users] Spec - Layout behaviour when resizing
On 12 Nov 2013, at 04:11, Bahman Movaqar bah...@bahmanm.com wrote:On 11/11/2013 22:52, Benjamin wrote:I do not get the image, but I know what happened :)Oops! Corrected that.No problem :)On 11 Nov 2013, at 20:08, Bahman Movaqar bah...@bahmanm.commailto:bah...@bahmanm.com wrote:When a window is resized, every Row/ColumnLayoutdistributes the widthand height evenly among any widget or nested layouts it contains. Inturn, widgets try to fill as much space as possible. Therefore afterresizing text box and button have become so huge and the spacebetween the radio buttons has increased so much.Is that correct?It’s correct in the sense it is expected regarding to the layout youuse :)If yes, I have a couple of points to mention: 1. A text box, specially in the case of TextModel and TextInputFieldModel, where it's basically a single line entry (ENTER is not allowed), should not change height (growing width is understandable and desired). The height of a text box (specially a single line one) should only be calculated based on the font family and font size.TextModel is for more that one line :)TextInputField could eventually be forced to be one line, but I thinkit’s too much of a restriction.I am 100% sure I didn't tell TextInputField to accept one line. Itdoesn't accept ENTER and I don't understand how a "multi-line" textentry widget can work without accepting new line character :-)Yes, TextInputField wraps the text but that's doesn't count asmulti-line entry :-) More importantly it is unexpected behaviour fromuser's PoV; I have never seen a single text entry widget wrap the text.Or maybe I'm doing something wrong?I do not understand sorry :(1. 2. A button should not change height and width, unless specifically mentioned otherwise.Why ?Because if the button changes height/width it loses the visual elementwhich users use to recognise buttons across a screen. Just like asingle-line text entry, a button's height, if not manually set, isdetermined only by the font family and font size.And regarding changing the button width, I've very rarely seenapplications that resize their buttons when the screen is resized.Usually people put constraints over this. I'm not stating that thisdefinitely should be some UI framework's internal mehcanism. Perhaps asimple method like `isCalculatedSize: aBoolean` with a TRUE default isenough.That’s true changing the size is often not desired.Adding a flag can be a solution :)But as it brings some more complexity in the layouting ( which is alreadyquite too complex and too big) it was not considered until now :) 3. It's not usually desirable that the spacing between radio buttons change.That’s true :) But how to know that two radio buttons are close one to the other ?Right. That's the reason radio button groups are, AFAIK, alwaysimplemented as widgets.Yes, but morphic do not do that :PMyabe I should introduce a model for that, and have my own encapsulation :) 4. Usually there's a way to specify how to distribute the width/height between layouts and widgets inside a layout (usually based on a percentage).There in spec as well :)You can have a look at:add:origin:corner:offsetOrigin:offsetCorner:Hmm...couldn't figure out the logic. Though it seems simple whenlooking at the code :-)Here you entrer in some twilight zone :Padd:origin:corner:offsetOrigin:offsetCorner:This screen shows an origin in x0,y0 and a corner in x1,y1.Their values are between 0 and 1, and represent a _proportional_ value of the container.Then, each of this corners can be shifted in x and y by a _fixed_ value (in pixels)BenThe best case I could get was a button with fixed width but a variableheight. Could you please help me out a bit here?-- Bahman Movaqar (http://BahmanM.com)ERP Evaluation, Implementation Deployment ConsultantPGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] How to add tabs in Nautilus
The easier way is to wait for me to finish the new Nautilus with tabs in it :P Ben On 12 Nov 2013, at 17:50, kilon alios kilon.al...@gmail.com wrote: I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. So how I add other tabs ?
Re: [Pharo-users] How to add tabs in Nautilus
On 12 Nov 2013, at 19:53, kilon alios kilon.al...@gmail.com wrote: hahahaha nicely played man , nicely played :D of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. Me too :) That’s why I am writing a new one (made with Spec) Otherwise, in full morphic, you will see the pain it is :P Ben On Tue, Nov 12, 2013 at 8:47 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: The easier way is to wait for me to finish the new Nautilus with tabs in it :P Ben On 12 Nov 2013, at 17:50, kilon alios kilon.al...@gmail.com wrote: I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. So how I add other tabs ?
Re: [Pharo-users] Spec - Layout behaviour when resizing
Ben On 12 Nov 2013, at 19:46, b...@openinworld.com wrote: Bahman Movaqar wrote: On 11/12/2013 17:29, Benjamin wrote: On 11 Nov 2013, at 20:08, Bahman Movaqar bah...@bahmanm.com mailto:bah...@bahmanm.com mailto:bah...@bahmanm.com wrote: When a window is resized, every Row/ColumnLayoutdistributes the width and height evenly among any widget or nested layouts it contains. In turn, widgets try to fill as much space as possible. Therefore after resizing text box and button have become so huge and the space between the radio buttons has increased so much. Is that correct? It’s correct in the sense it is expected regarding to the layout you use :) If yes, I have a couple of points to mention: 1. A text box, specially in the case of TextModel and TextInputFieldModel, where it's basically a single line entry (ENTER is not allowed), should not change height (growing width is understandable and desired). The height of a text box (specially a single line one) should only be calculated based on the font family and font size. TextModel is for more that one line :) TextInputField could eventually be forced to be one line, but I think it’s too much of a restriction. I am 100% sure I didn't tell TextInputField to accept one line. It doesn't accept ENTER and I don't understand how a multi-line text entry widget can work without accepting new line character :-) Yes, TextInputField wraps the text but that's doesn't count as multi-line entry :-) More importantly it is unexpected behaviour from user's PoV; I have never seen a single text entry widget wrap the text. Or maybe I'm doing something wrong? I do not understand sorry :( Put in other words: 1. The default behaviour (if there's any other behaviour) of a text box in Spec, doesn't accept ENTER. A multi-line text entry without ENTER doesn't make sense, no? What enter does then ? 2. The default behaviour of a Spec text box, wraps the text entered if the length exceeds the display length of the widget. This is very unorthodox and wrong *from user's perspective*. What is expected ? Which widget of text ? This behaviour is actually Morphic behaviour, not Spec. But anyway, it can/should be fixed/improved :) I have to support point 2 above. In general terms... For a single line text box, I would expect it to scroll text horizontally out of view. I would expect initially at least two lines for a wrapping text box, after which it can be free to grow vertically as needed. cheers -ben 1. 2. A button should not change height and width, unless specifically mentioned otherwise. Why ? Because if the button changes height/width it loses the visual element which users use to recognise buttons across a screen. Just like a single-line text entry, a button's height, if not manually set, is determined only by the font family and font size. And regarding changing the button width, I've very rarely seen applications that resize their buttons when the screen is resized. Usually people put constraints over this. I'm not stating that this definitely should be some UI framework's internal mehcanism. Perhaps a simple method like `isCalculatedSize: aBoolean` with a TRUE default is enough. That’s true changing the size is often not desired. Adding a flag can be a solution :) But as it brings some more complexity in the layouting ( which is already quite too complex and too big) it was not considered until now :) Makes sense. 3. It's not usually desirable that the spacing between radio buttons change. That’s true :) But how to know that two radio buttons are close one to the other ? Right. That's the reason radio button groups are, AFAIK, always implemented as widgets. Yes, but morphic do not do that :P Myabe I should introduce a model for that, and have my own encapsulation :) Perfect idea. And along with some documentation please :-D 4. Usually there's a way to specify how to distribute the width/height between layouts and widgets inside a layout (usually based on a percentage). There in spec as well :) You can have a look at: add:origin:corner:offsetOrigin:offsetCorner: Hmm...couldn't figure out the logic. Though it seems simple when looking at the code :-) Here you entrer in some twilight zone :P add:origin:corner:offsetOrigin:offsetCorner: This screen shows an origin in x0,y0 and a corner in x1,y1. Their values are between 0 and 1, and represent a _proportional_ value of the container. By the gods! How was I supposed to know the values were supposed to be 01 !? :-) Thank you for this tip! Everybody should know that :P Then, each of this corners can be shifted in x and y by a _fixed_ value (in pixels) So basically `add: #buttonGreet origin: 0.3@0.2 corner: 0.7@0.5 offsetOrigin: 0@0
Re: [Pharo-users] How to add tabs in Nautilus
What is exactly your goal ? :) Ben On 12 Nov 2013, at 20:46, kilon alios kilon.al...@gmail.com wrote: yeah morphic is quite messy , but hey it works Thank you for your effort to bring us a better , cleaner and simpler GUI API. You have my support. I am actually thinking about implementing my own GUI API and I was wondering if I should base it on spec or not. My main focus is custom look guis. But I will wait for the documentation of spec to appear before I make any decision on it. On Tue, Nov 12, 2013 at 9:23 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 12 Nov 2013, at 19:53, kilon alios kilon.al...@gmail.com wrote: hahahaha nicely played man , nicely played :D of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. Me too :) That’s why I am writing a new one (made with Spec) Otherwise, in full morphic, you will see the pain it is :P Ben On Tue, Nov 12, 2013 at 8:47 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: The easier way is to wait for me to finish the new Nautilus with tabs in it :P Ben On 12 Nov 2013, at 17:50, kilon alios kilon.al...@gmail.com wrote: I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. So how I add other tabs ?
Re: [Pharo-users] How to add tabs in Nautilus
On 12 Nov 2013, at 23:07, kilon alios kilon.al...@gmail.com wrote: Currently I am working on Hyperion a vector graphics editor with similar goals to inkscape and gimp . The second step will be to use Hyperion as a GUI designer, not just to drag and drop ready made widgets but to design from scratch new ones. The third step is to create a GUI api so that those widgets will be accessed from code via a GUI API that I have named Morpheas. The forth step is to take all that and redesign the look (just the look not the internals) of Pharo making it more user friendly and approachable including several tools into a project I have named Ephestos. This sounds like a really cool battle plan :) I sincerely wish you to succeed in your project :) I like the general idea of everything being a morph a simple building block that allows you to build complex , custom guis. I am also thinking providing a super simple GUI API and offering sophisticated widgets as external libraries. In sort my goal is minimalism and customisation. All of this will be based on Athens which is what I already use for Hyperion. This is the final look that aiming for to offer as a default look , but of course because it will be based on Athens and will offer a powerful designer any look will be possible. http://vimeo.com/68113915 Currently I just started Hyperion and I work at creating lines with Athens and editing them graphically like inkscape. I hope that after 6 months to finish the basic vector graphic editing capabilities and move to GUI design so that by 2015 I have version 1 to offer that will be able to do both. Of course this will be a way more long term project than just one year but for now I take it step by step , day by day and see where it takes me. Because it is based on Athens I can bypass spec and even morphic completely and offer my own GUI API, however that will make it hard for people already having projects in those APIs to move to mine and since spec looks like the future of Pharo I am seriously considering spec as well. It will also save me the trouble of designing my own GUI API which is of course a big plus. My own concern is how morphic friendly spec is, meaning that I want to see everything as a composition of simpler elements and not monolithic widgets. From what I have seen from some tutorials this seems to be the direction you go with this, but maybe you could illuminate that area abit more for me. The idea of Spec (and the direction I want to give him now) is to be framework independent, in a way one can plug any framework below as long as the correct adapters are provided :) So if you implement the basic widgets, then you should be able to compose them using Spec :) I will also be interested to hear where you want to take spec, what you will like to add etc. I think that some widgets are missing but not that much anymore :) So I think the next steps are bug fixes and documentation :) Ben On Tue, Nov 12, 2013 at 11:27 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: What is exactly your goal ? :) Ben On 12 Nov 2013, at 20:46, kilon alios kilon.al...@gmail.com wrote: yeah morphic is quite messy , but hey it works Thank you for your effort to bring us a better , cleaner and simpler GUI API. You have my support. I am actually thinking about implementing my own GUI API and I was wondering if I should base it on spec or not. My main focus is custom look guis. But I will wait for the documentation of spec to appear before I make any decision on it. On Tue, Nov 12, 2013 at 9:23 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 12 Nov 2013, at 19:53, kilon alios kilon.al...@gmail.com wrote: hahahaha nicely played man , nicely played :D of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. Me too :) That’s why I am writing a new one (made with Spec) Otherwise, in full morphic, you will see the pain it is :P Ben On Tue, Nov 12, 2013 at 8:47 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: The easier way is to wait for me to finish the new Nautilus with tabs in it :P Ben On 12 Nov 2013, at 17:50, kilon alios kilon.al...@gmail.com wrote: I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. So how I add other tabs ?
Re: [Pharo-users] How to add tabs in Nautilus
On 12 Nov 2013, at 23:37, kilon alios kilon.al...@gmail.com wrote: Thank you for the wishes. I would not even dream to start something like that if Pharo did not already offer so many awesome libraries and tools. Ah thats very good news indeed , I did not know you were so much close to finalizing at least the core of spec. Documentation is something I am already looking forward to. So it seems I will be using Spec afterall. Are you by any chance thinking about a theme engine about Spec , because this generally the direction I am going with this . I dont know if you have used Winamp on windows, its a music player that can change skins and even though it has the same gui it can change its look dramatically. I think such an ability would look very cool for Pharo and its what I am aiming for with my project. So does Spec has any theme support ? If not any plans for it , or you leave that to others to make ? This is not planned yet (mainly because I do not have time to do it), but if someone wants to contribute, he/she is more than welcome :) Ben These are some examples of winamp skins http://www.winamp.com/skins On Wed, Nov 13, 2013 at 12:23 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 12 Nov 2013, at 23:07, kilon alios kilon.al...@gmail.com wrote: Currently I am working on Hyperion a vector graphics editor with similar goals to inkscape and gimp . The second step will be to use Hyperion as a GUI designer, not just to drag and drop ready made widgets but to design from scratch new ones. The third step is to create a GUI api so that those widgets will be accessed from code via a GUI API that I have named Morpheas. The forth step is to take all that and redesign the look (just the look not the internals) of Pharo making it more user friendly and approachable including several tools into a project I have named Ephestos. This sounds like a really cool battle plan :) I sincerely wish you to succeed in your project :) I like the general idea of everything being a morph a simple building block that allows you to build complex , custom guis. I am also thinking providing a super simple GUI API and offering sophisticated widgets as external libraries. In sort my goal is minimalism and customisation. All of this will be based on Athens which is what I already use for Hyperion. This is the final look that aiming for to offer as a default look , but of course because it will be based on Athens and will offer a powerful designer any look will be possible. http://vimeo.com/68113915 Currently I just started Hyperion and I work at creating lines with Athens and editing them graphically like inkscape. I hope that after 6 months to finish the basic vector graphic editing capabilities and move to GUI design so that by 2015 I have version 1 to offer that will be able to do both. Of course this will be a way more long term project than just one year but for now I take it step by step , day by day and see where it takes me. Because it is based on Athens I can bypass spec and even morphic completely and offer my own GUI API, however that will make it hard for people already having projects in those APIs to move to mine and since spec looks like the future of Pharo I am seriously considering spec as well. It will also save me the trouble of designing my own GUI API which is of course a big plus. My own concern is how morphic friendly spec is, meaning that I want to see everything as a composition of simpler elements and not monolithic widgets. From what I have seen from some tutorials this seems to be the direction you go with this, but maybe you could illuminate that area abit more for me. The idea of Spec (and the direction I want to give him now) is to be framework independent, in a way one can plug any framework below as long as the correct adapters are provided :) So if you implement the basic widgets, then you should be able to compose them using Spec :) I will also be interested to hear where you want to take spec, what you will like to add etc. I think that some widgets are missing but not that much anymore :) So I think the next steps are bug fixes and documentation :) Ben On Tue, Nov 12, 2013 at 11:27 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: What is exactly your goal ? :) Ben On 12 Nov 2013, at 20:46, kilon alios kilon.al...@gmail.com wrote: yeah morphic is quite messy , but hey it works Thank you for your effort to bring us a better , cleaner and simpler GUI API. You have my support. I am actually thinking about implementing my own GUI API and I was wondering if I should base it on spec or not. My main focus is custom look guis. But I will wait for the documentation of spec to appear before I make any decision on it. On Tue, Nov 12, 2013 at 9:23 PM, Benjamin benjamin.vanryseghem.ph
Re: [Pharo-users] Spec - Grid/Table Layout
I am sure that Adapters understands widgetDo:
To which objects do you send this message ?
Ben
On 11 Nov 2013, at 11:08, prova email prova...@hotmail.it wrote:
Hi Ben,
are you sure that the message widgetDo: is the right one? It's not a
message that my object looks to understand.
Thanks in advance.
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 14:34:18 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
It is definitely defined in TreeModel :)
Ben
On 08 Nov 2013, at 14:29, prova email prova...@hotmail.it wrote:
Very very very good Ben, thanks a lot. Last question: you use the columns:
message, but it's not defined in TreeModel. You defined it here
MorphTreeAdapter#columns:
columns: columns
self widgetDo: [ :w |
w columns: columns.
w resizerChanged.
w updateList ]
in the brand new Class MorphTreeAdapter. What's the difference between define
columns: here instead of in the TreeModel class?
Great job and thank you!
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 14:15:46 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
tree := TreeModel new.
tree openWithSpec.
tree columns: (Array
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
first asString asMorph ]; headerButtonLabel: 'Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
second asString asMorph ]; headerButtonLabel: 'Last Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
third asString asMorph ]; headerButtonLabel: 'Age' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
fourth asString asMorph ]; headerButtonLabel: 'Gender' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | (ButtonModel
new label: 'Yes we can') buildWithSpec hResizing: #spaceFill];
headerButtonLabel: 'Morph' font: nil; yourself)).
tree roots: {
{'Benjamin'.'Van Ryseghem'.'26'.'M'}.
{'Pamela'.'Anderson'.'Far too much'.'F'}
}
Ben
On 08 Nov 2013, at 14:05, prova email prova...@hotmail.it wrote:
Yes Ben, too much threads! That's why i'm a little bit confused! That's what
i understood: i've got two roads- use TreeModel as you did with Pamela
Anderson or use the simple and nested SpecLayout (SpecLayout composed) as
Clement did.
If in your TreeModel i can put a RadioButtonModel or a ButtonModel or so
on... we got the deal!
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 13:59:51 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
I guess too much threads :)
I answer this in another thread I think :P
the block provided to displayBlock:/rowMorphGetSelector: can return anything
understanding asMorph.
So you can return any custom morph there :)
I think the following work
tree columns: (Array
with: (TreeColumnModel new displayBlock: [:node | node content first
asString ]; headerLabel: 'Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content second
asString ]; headerLabel: 'Last Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content third
asString ]; headerLabel: 'Age'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content fourth
asString ]; headerLabel: 'Gender'; yourself)
with: (TreeColumnModel new displayBlock: [:node | Morph new ];
headerLabel: ‘Morph'; yourself))
or
tree columns: (Array
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
first asString asMorph ]; headerButtonLabel: 'Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
second asString asMorph ]; headerButtonLabel: 'Last Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
third asString asMorph ]; headerButtonLabel: 'Age' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
fourth asString asMorph ]; headerButtonLabel: 'Gender' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | Morph new ];
headerButtonLabel: 'Morph' font: nil; yourself)).
And you get something like
Screen Shot 2013-11-08 at 13.58.51.png
Ben
On 08 Nov 2013, at 13:45, prova email prova...@hotmail.it wrote:
Yes Clement, i've got your .st file. I saw it in Nested Layout thread. I file
in it in Pharo and i see that is not as good as a fashion window is. Maybe
Morphic is the right solution but, in that way, we are leaving the idea of
Bahman, and the 2nd Spec Tuto
Re: [Pharo-users] Spec - Grid/Table Layout
Now I get it :)
This is not supported in 2.0 in the sense that the Spec version shipped with
Pharo 2.0 has evolved :)
You can try it in Pharo 3.0 :)
Ben
On 11 Nov 2013, at 12:08, prova email prova...@hotmail.it wrote:
I'm doing a TreeModel. As you know, widgetDo is not a message of TreeModel,
that's why i was asking you if there something wrong. As i asked you in a old
post, column: is not a message of TreeModel, so, where do i have to create
that message? The following code means to me that i have to create column:
into MorphTreeAdapter, a class that i haven't got into my Pharo 2.0.
MorphTreeAdapter#columns:
columns: columns
self widgetDo: [ :w |
w columns: columns.
w resizerChanged.
w updateList ]
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Mon, 11 Nov 2013 12:03:13 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
I am sure that Adapters understands widgetDo:
To which objects do you send this message ?
Ben
On 11 Nov 2013, at 11:08, prova email prova...@hotmail.it wrote:
Hi Ben,
are you sure that the message widgetDo: is the right one? It's not a
message that my object looks to understand.
Thanks in advance.
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 14:34:18 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
It is definitely defined in TreeModel :)
Ben
On 08 Nov 2013, at 14:29, prova email prova...@hotmail.it wrote:
Very very very good Ben, thanks a lot. Last question: you use the columns:
message, but it's not defined in TreeModel. You defined it here
MorphTreeAdapter#columns:
columns: columns
self widgetDo: [ :w |
w columns: columns.
w resizerChanged.
w updateList ]
in the brand new Class MorphTreeAdapter. What's the difference between define
columns: here instead of in the TreeModel class?
Great job and thank you!
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 14:15:46 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
tree := TreeModel new.
tree openWithSpec.
tree columns: (Array
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
first asString asMorph ]; headerButtonLabel: 'Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
second asString asMorph ]; headerButtonLabel: 'Last Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
third asString asMorph ]; headerButtonLabel: 'Age' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
fourth asString asMorph ]; headerButtonLabel: 'Gender' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | (ButtonModel
new label: 'Yes we can') buildWithSpec hResizing: #spaceFill];
headerButtonLabel: 'Morph' font: nil; yourself)).
tree roots: {
{'Benjamin'.'Van Ryseghem'.'26'.'M'}.
{'Pamela'.'Anderson'.'Far too much'.'F'}
}
Ben
On 08 Nov 2013, at 14:05, prova email prova...@hotmail.it wrote:
Yes Ben, too much threads! That's why i'm a little bit confused! That's what
i understood: i've got two roads- use TreeModel as you did with Pamela
Anderson or use the simple and nested SpecLayout (SpecLayout composed) as
Clement did.
If in your TreeModel i can put a RadioButtonModel or a ButtonModel or so
on... we got the deal!
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 13:59:51 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
I guess too much threads :)
I answer this in another thread I think :P
the block provided to displayBlock:/rowMorphGetSelector: can return anything
understanding asMorph.
So you can return any custom morph there :)
I think the following work
tree columns: (Array
with: (TreeColumnModel new displayBlock: [:node | node content first
asString ]; headerLabel: 'Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content second
asString ]; headerLabel: 'Last Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content third
asString ]; headerLabel: 'Age'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content fourth
asString ]; headerLabel: 'Gender'; yourself)
with: (TreeColumnModel new displayBlock: [:node | Morph new ];
headerLabel: ‘Morph'; yourself))
or
tree columns: (Array
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
first asString asMorph
Re: [Pharo-users] Spec - Layout behaviour when resizing
I do not get the image, but I know what happened :) On 11 Nov 2013, at 20:08, Bahman Movaqar bah...@bahmanm.com wrote: Hi all, Let's assume I have a window like the one in episode 2 of the tutorial. Some unexpected (from the user's perspective) behaviour happens when I manually resize the window. A snapshot is worth a thousand words (and I'm going to put two snapshots here!). This is the fresh window that I just opened: The same window after resizing: So this is my understanding: When a window is resized, every Row/ColumnLayout distributes the width and height evenly among any widget or nested layouts it contains. In turn, widgets try to fill as much space as possible. Therefore after resizing text box and button have become so huge and the space between the radio buttons has increased so much. Is that correct? It’s correct in the sense it is expected regarding to the layout you use :) If yes, I have a couple of points to mention: A text box, specially in the case of TextModel and TextInputFieldModel, where it's basically a single line entry (ENTER is not allowed), should not change height (growing width is understandable and desired). The height of a text box (specially a single line one) should only be calculated based on the font family and font size. TextModel is for more that one line :) TextInputField could eventually be forced to be one line, but I think it’s too much of a restriction A button should not change height and width, unless specifically mentioned otherwise. Why ? It's not usually desirable that the spacing between radio buttons change. That’s true :) But how to know that two radio buttons are close one to the other ? Usually there's a way to specify how to distribute the width/height between layouts and widgets inside a layout (usually based on a percentage). There in spec as well :) You can have a look at: add:origin:corner:offsetOrigin:offsetCorner: Ben I'd appreciate if anyone could shed a light here; specially Benjamin the Undocumenter :-) -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Disable auto-complete in text box
try entryCompletion: nil and tell me if it does the job :) Ben On 11 Nov 2013, at 19:21, Bahman Movaqar bah...@bahmanm.com wrote: Hi all, Is it possible to disable auto-completion in a text box? I've tried `textName isCodeCompletionAllowed: false` to no avail. Am I doing it wrong? Any other way to do it? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] How to change background color
A good pointer would be to add support for color on AbstractWidget and change a bit the way MorphicAdapters are built to take this color in account Ben On 11 Nov 2013, at 21:42, Gisela Decuzzi giseladecu...@gmail.com wrote: Hi, I'm getting some problems trying to change the default colors for the widgets. I need to replace the gray color for a blue (yes, quite horrible, long history). I'm using Spec and didn't find how to do this, and after trying I end up hacking in morph. Is there a way to do this? Or someone can show me a starting point?
Re: [Pharo-users] How to change background color
Cool :) Keep me in touch then :) I am visiting a customer this week, so I do not have all the time I would to test it, but I will give a try as soon as I can :) Ben On 11 Nov 2013, at 22:13, Sergi Reyner sergi.rey...@gmail.com wrote: 2013/11/11 Benjamin benjamin.vanryseghem.ph...@gmail.com A good pointer would be to add support for color on AbstractWidget and change a bit the way MorphicAdapters are built to take this color in account Hmmm... I may or may not give it a try tonight/tomorrow morning :) Cheers, Sergi
Re: [Pharo-users] Adjusting the size of a window using Spec
This was indeed my goal :) Having kind of solid documentation for 3.0 release. Spec was in 2.0 because we already had some tools already re implemented in Spec but also that people can know it exists before it becomes “mainstream Ben On 10 Nov 2013, at 04:45, b...@openinworld.com wrote: Benjamin wrote: Shame on you dude :P It points out the huge lack of Spec documentation, so in fact, shame on me :P Ben I'm not sure how much Pharo 2.0 focused on the move to Spec for UI (I've ended up jumping from 1.4 straight to 3.0alpha) but regarding the professional presentation/reception of Pharo I feel some solid Spec documentation will be critical to coincide with the 3.0 release (or very shortly thereafter). Even though there has been a great amount of other work under-the-hood, Spec is the front-line system that end-user-developers will be working with. I'm sure that already was your aim. This is just a supporting note for that action. cheers -ben On 09 Nov 2013, at 20:34, Sean P. DeNigris s...@clipperadams.com wrote: Benjamin Van Ryseghem-2 wrote You just need to override the method #initialExtent Cool! I didn't know that one. I've been writing ugly #open methods which call #extent:... - Cheers, Sean -- View this message in context: http://forum.world.st/Adjusting-the-size-of-a-window-using-Spec-tp4719478p4720806.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec setting color (was Re: Spec - Tutorial Series)
I think it’s currently missing. Not that much to implement though, but still not here :P Ben On 09 Nov 2013, at 18:26, b...@openinworld.com wrote: Bahman Movaqar wrote: Hi all, A new episode is availabe: Spec - Part II: The Layout (http://www.bahmanm.com/blogs/spec-part-2-layout) I'd appreciate any comments/hints. TIA, Question to Spec gevelopers... Referring to Bahman's example, how do you set the color of: * the 'Greet Me' button - I tried adding buttonGreet color: Color red. to both #initializeWidgets and #initializePresenter, with no error, but also no effect. * dialog background - I don't see anything like #color under ComposableModel. cheers -ben
Re: [Pharo-users] Spec - Tutorial Series
On 09 Nov 2013, at 09:53, b...@openinworld.com wrote: Bahman Movaqar wrote: Hi all, A new episode is availabe: Spec - Part II: The Layout (http://www.bahmanm.com/blogs/spec-part-2-layout) I'd appreciate any comments/hints. TIA, Some minor nit-picks... please do so as we are going to iterate over what was done there. I don't understand what you mean by 'iterate over'? Do you me 'build on'? let's first settle for a target design. For the rest of this episode, we will try to achieve the following design. I get to the bottom and the last snapshot it doesn't look the same as the one at the top. At the top you should mention that your target design is achieved over several posts (if that is the case). Note lines 9, 10, 17 and 18. Note new lines 9, 10, 17 and 18. * At the top you should specify what version of Pharo the tutorial relates to. Information on the web hangs around for a very long time and someone could get trapped later trying your tutorial on a later version of Pharo. * Regarding #defaultSpec, I happen to like what is used in PharoLauncher specLayout spec: #default ^ SpecLayout composed …etc The pragma should be preferred :) Actually the check is done like this: - take the first method found with defaultSpec (if multiple, te first found is used) - if none, and there is only one method with the pragma spec, use it - otherwise look for defaultSpec (this should be deprecated soon) - DNU the defaultSpec is a relic of the first version of Spec :) Overall it a nice next step introducing just a bit more functionality. It reads very well. I look forward to the next one. cheers -ben P.S. Some questions for Spec gurus... * looking at #defaultSpec from this episode, if the pattern is always... mainColumn newRow: [ :aRow | aRow doStuff; otherStuff... ] what is gained over a pattern like... mainColumn newRow doStuff ; otherStuff. As I understood your question, you answered it :) I use block here so one can easily have a pointer to the row to do some magic here :) It also represents the columns/rows hierarchy * is #defaultSpec always going to return a SpecLayout? In which case #defaultSpec feels like is should be #defaultSpecLayout. Even if it returns a SpecLayout most of the time, it could as well return an array with a spec structure. Actually, when you return a SpecLayout, it is converted into an array before wing interpreted :) (try to inspect one of your favorite SpecLayout and look at myLayout asArray ^^) cheers -ben
Re: [Pharo-users] Spec - Nested Layouts
Cool :) As soon as the last piece is integrated I will send a mail to announce it with some explanations, examples, and how to migrate :) Ben On 09 Nov 2013, at 13:41, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Nov 7, 2013, at 10:07 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: integrated - 11920 (the valueHolder one) - 12054 (TreeNode and TreeColumn) - There is one also about SpecMenu, I do not remember the number https://pharo.fogbugz.com/f/cases/12051/Add-MenuModels are on work needed but this is unclear to me. I will check and probably integrate it and please let us know. https://pharo.fogbugz.com/f/cases/12050 got integrated Stef
Re: [Pharo-users] Spec - Grid/Table Layout
In the example I gave with TreeColumn/MorphTreeColumn the block used to render the item can return anything understanding #asMorph. So you can easily return any Morph you like there :) Ben On 08 Nov 2013, at 12:18, prova email prova...@hotmail.it wrote: Hi Clement; I did the Spec tuto made by Bahman (great tuto). As him, i'd like to put some widgets into it. Is it possible? Maybe with the method items:? I don't know if the solution that Ben give to us (use Morphic instead of Spec) is suitable, that's because his UI looks like a list that accept only string. Maybe i'm wrong, can you give us more explanations? Or is it something new for you too? Thanks for your help! Paolo From: bera.clem...@gmail.com Date: Thu, 7 Nov 2013 10:04:51 +0100 To: bah...@bahmanm.com; pharo-users@lists.pharo.org Subject: Re: [Pharo-users] Spec - Grid/Table Layout Hello, Actually I had the same problem, I think the best widget that exists for that right now is MultiColumnListModel. For example, in the senders window (in attachment), the top panel is a MultiColumnListModel. You can have as many lines and as many columns as you want. We do not have yet a tableLayout, but we miss it. If you plan to implement it, we will be interested in integrating it into Pharo. Ben can advise you on how to implement that. Screen Shot 2013-11-07 at 10.00.55 AM.png 2013/11/7 Bahman Movaqar bah...@bahmanm.com Hi all, Is there a grid/table layout available in Spec? Something like an HTML table or Swing's GridLayout? If not, how may I achieve such a functionality? I'd appreciate any hints/pointers. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Grid/Table Layout
tree := TreeModel new.
tree openWithSpec.
tree columns: (Array
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
first asString asMorph ]; headerButtonLabel: 'Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
second asString asMorph ]; headerButtonLabel: 'Last Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
third asString asMorph ]; headerButtonLabel: 'Age' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
fourth asString asMorph ]; headerButtonLabel: 'Gender' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | (ButtonModel
new label: 'Yes we can') buildWithSpec hResizing: #spaceFill];
headerButtonLabel: 'Morph' font: nil; yourself)).
tree roots: {
{'Benjamin'.'Van Ryseghem'.'26'.'M'}.
{'Pamela'.'Anderson'.'Far too much'.'F'}
}
Ben
On 08 Nov 2013, at 14:05, prova email prova...@hotmail.it wrote:
Yes Ben, too much threads! That's why i'm a little bit confused! That's what
i understood: i've got two roads- use TreeModel as you did with Pamela
Anderson or use the simple and nested SpecLayout (SpecLayout composed) as
Clement did.
If in your TreeModel i can put a RadioButtonModel or a ButtonModel or so
on... we got the deal!
Paolo
From: benjamin.vanryseghem.ph...@gmail.com
Date: Fri, 8 Nov 2013 13:59:51 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
I guess too much threads :)
I answer this in another thread I think :P
the block provided to displayBlock:/rowMorphGetSelector: can return anything
understanding asMorph.
So you can return any custom morph there :)
I think the following work
tree columns: (Array
with: (TreeColumnModel new displayBlock: [:node | node content first
asString ]; headerLabel: 'Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content second
asString ]; headerLabel: 'Last Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content third
asString ]; headerLabel: 'Age'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content fourth
asString ]; headerLabel: 'Gender'; yourself)
with: (TreeColumnModel new displayBlock: [:node | Morph new ];
headerLabel: ‘Morph'; yourself))
or
tree columns: (Array
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
first asString asMorph ]; headerButtonLabel: 'Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
second asString asMorph ]; headerButtonLabel: 'Last Name' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
third asString asMorph ]; headerButtonLabel: 'Age' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item
fourth asString asMorph ]; headerButtonLabel: 'Gender' font: nil; yourself)
with: (MorphTreeColumn new rowMorphGetSelector: [:node | Morph new ];
headerButtonLabel: 'Morph' font: nil; yourself)).
And you get something like
Screen Shot 2013-11-08 at 13.58.51.png
Ben
On 08 Nov 2013, at 13:45, prova email prova...@hotmail.it wrote:
Yes Clement, i've got your .st file. I saw it in Nested Layout thread. I file
in it in Pharo and i see that is not as good as a fashion window is. Maybe
Morphic is the right solution but, in that way, we are leaving the idea of
Bahman, and the 2nd Spec Tuto is in danger!
However, you asked to Ben the same question that i did: can i put some
widgets in these cells or only String?
Thanks again!
Paolo
From: bera.clem...@gmail.com
Date: Fri, 8 Nov 2013 12:51:06 +0100
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Spec - Grid/Table Layout
Ben answered in another thread:
About table, I have an example which will be running soon in Pharo (the
changes are waiting to be integrated)
tree := TreeModel new.
tree openWithSpec.
tree columns: (Array
with: (TreeColumnModel new displayBlock: [:node | node content first
asString ]; headerLabel: 'Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content second
asString ]; headerLabel: 'Last Name'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content third
asString ]; headerLabel: 'Age'; yourself)
with: (TreeColumnModel new displayBlock: [:node | node content fourth
asString ]; headerLabel: 'Gender'; yourself)).
tree roots: {
{'Benjamin'.'Van Ryseghem'.'26'.'M'}.
{'Pamela'.'Anderson'.'Far too much'.'F'}
}
Right now, you can get the same by
- adding MorphTreeAdapter#columns:
columns: columns
self widgetDo: [ :w |
w columns: columns
Re: [Pharo-users] Spec - TextModel whenTextIsAccepted
Somehow it’s true. And you could try it :) But while doing Spec I also fixed a lot of bugs in the morphic widgets themselves :) Try with the latest spec, and tell me :P Ben On 07 Nov 2013, at 05:38, Bahman Movaqar bah...@bahmanm.com wrote: On 11/06/2013 20:35, Benjamin wrote: Ok :) These methods only exists in Pharo 3.0 :) Hmm...I don't understand. Please correct me if I'm wrong but I thought Spec is a UI library, so it doesn't matter if I'm using it in Pharo 2.0 or 3.0 as long as I have the correct version of Spec. On 06 Nov 2013, at 08:38, Bahman Movaqar bah...@bahmanm.com wrote: On 11/06/2013 11:07, Benjamin wrote: In which version of Pharo are you working ? Pharo2.0 Latest update: #20607 On 06 Nov 2013, at 08:31, Bahman Movaqar bah...@bahmanm.com wrote: On 11/06/2013 10:56, Benjamin wrote: On 06 Nov 2013, at 08:21, Bahman Movaqar bah...@bahmanm.com mailto:bah...@bahmanm.com wrote: On 11/06/2013 10:41, Benjamin wrote: This is the expected behaviour :) Oh! A bit unorthodox, specially considering the shortcut (CTRL+S) --I was expecting something like ENTER :-) There is also acceptOnCr :) That clearly shows I have to work on my exploration skills :-) But what you can do (and actually what you wanna do) is to accept the text at each keyStroke :) initializePresenter self instantiateModels: #( textName TextModel labelGreetingLabelModel buttonGreetButtonModel ). labelGreeting text: ''. buttonGreet label: 'Greet Me!'; disable. should be turned into: #initializePresenter textName := self newTextInput. labelGreeting := self newLabel. buttonGreet := self newButton. Would you please explain the RHS of the statements? I don't understand `self newTextInput`. It’s equivalent to self instantiateModels: #(textName TextInputFieldModel). It simply creates a new sub model for you :) Hmm...Pharo rejects those lines, e.g. with Unknown select newTextInput. I guess I'm sub-classing the wrong class. Here's my class definition: code ComposableModel subclass: #FirstSpec instanceVariableNames: 'textName labelGreeting buttonGreet' classVariableNames: '' poolDictionaries: '' category: 'Bahman-Spec' /code labelGreeting text: ''. buttonGreet label: 'Greet Me!'; disable. textName autoAccept: true. It's certainly no big deal but I'm just curious; any special reason why `autoAccept` doesn't default to true? That’s actually a good question :) I guess the answer is historical :) Ancestral remains, huh? :-) On 06 Nov 2013, at 06:05, Bahman Movaqar bah...@bahmanm.com mailto:bah...@bahmanm.com wrote: Hi all, I'm writing a simple graphical version of the legendary Hello, world. I have a window with a text field, a button and a label. What I'm trying to do is to make the button (which is initially disabled) enabled upon user entering text. However, it seems that the user first must Accept the text for the action to be fired. Here's some snippets of code: code initializePresenter textName whenTextChanged: [ buttonGreet enable ]. buttonGreet action: [ labelGreeting text: 'Hello, ', textName text, '!'. buttonGreet disable ]. initializeWidgets self instantiateModels: #( textName TextModel labelGreetingLabelModel buttonGreetButtonModel ). labelGreeting text: ''. buttonGreet label: 'Greet Me!'; disable. /code What am I doing wrong? TIA, PS: I have tried `whenTextChanged` to no avail --it shows the same behaviour. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Grid/Table Layout
Such a UIcan be achieve with a MorphTreeMorph (therefor with a TreeModel in Spec).Maybe I should create a TableModel in addition since a TreeModel for this is a bit magic :) Ben On 07 Nov 2013, at 10:04, Clément Bera bera.clem...@gmail.com wrote:Hello,Actually I had the same problem, I think the best widget that exists for that right now isMultiColumnListModel.For example, in the senders window (in attachment), the top panel is a MultiColumnListModel. You can have as many lines and as many columns as you want. We do not have yet a tableLayout, but we miss it. If you plan to implement it, we will be interested in integrating it into Pharo.Ben can advise you on how to implement that. Screen Shot 2013-11-07 at 10.00.55 AM.png2013/11/7 Bahman Movaqar bah...@bahmanm.com Hi all, Is there a grid/table layout available in Spec? Something like an HTML table or Swing's GridLayout? If not, how may I achieve such a functionality? I'd appreciate any hints/pointers. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Nested Layouts
Cool :) I think what Clement answered is what you wanted :) Alos, see the other thread, you can do table by tweaking a TreeModel :) Ben On 07 Nov 2013, at 11:08, Bahman Movaqar bah...@bahmanm.com wrote: On 11/07/2013 12:45, Clément Bera wrote: Hey, I don't know what you want exactly. Right. I had a feeling that I'd asked it the wrong way :-) What I'd like to know is that can I mimic a table layout by nesting column and row layouts? You can do: spec spec ^ SpecLayout composed newRow: [:row | row newColumn: [ :col | col add: #list width: 135; add: #description ] ]; yourself and nest that as many times as you want (but I don't know if this was your question). Another feature is: debuggerSpec spec: #default ^ SpecLayout composed add: #inspector withSpec: #debuggerSpec; yourself #inspector being the instance variable name that holds a subclass of ComposableModel that defines class side #debuggerSpec, which answers a SpecLayout. Not sure if this helped. Thanks. I'll give this a try and let you know. All of these questions are for your tutorials ? Yes. Actually I'm trying to build a UI for Fossil DVCS with Pharo. And in the meantime, I document what I learn hoping it will save somebody else's time :-) 2013/11/7 Bahman Movaqar bah...@bahmanm.com Hi all, Is it possible to nest layouts in Spec? For example can I combine `SpecColumnLayout` and `SpecRowLayout` together? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Grid/Table Layout
On 07 Nov 2013, at 12:04, Bahman Movaqar bah...@bahmanm.com wrote: On 11/07/2013 12:34, Clément Bera wrote: Hello, Actually I had the same problem, I think the best widget that exists for that right now is MultiColumnListModel. For example, in the senders window (in attachment), the top panel is a MultiColumnListModel. You can have as many lines and as many columns as you want. Great. Now I have to check if I can put widgets in those lines and columns instead of just text? We do not have yet a tableLayout, but we miss it. If you plan to implement it, we will be interested in integrating it into Pharo. No way! At least currently :-) I'm just too inexperienced for such serious stuff That’s a good way to learn :P Ben Ben can advise you on how to implement that. Mail Attachment.png 2013/11/7 Bahman Movaqar bah...@bahmanm.com Hi all, Is there a grid/table layout available in Spec? Something like an HTML table or Swing's GridLayout? If not, how may I achieve such a functionality? I'd appreciate any hints/pointers. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Nested Layouts
Just a general remark: you should try as much as possible to avoid hard coding width/height :) there are some methods on ComposableModel you could use like buttonHeight toolbarHeight etc. that you should use instead :) Ben On 07 Nov 2013, at 13:22, Bahman Movaqar bah...@bahmanm.com wrote: On 11/07/2013 12:45, Clément Bera wrote: Hey, I don't know what you want exactly. You can do: spec spec ^ SpecLayout composed newRow: [:row | row newColumn: [ :col | col add: #list width: 135; add: #description ] ]; yourself and nest that as many times as you want (but I don't know if this was your question). I just tried this one and it works (see the code below) BUT, the code is so hard to read and understand just for 3 rows and 7 widgets! code defaultSpec ^ SpecLayout composed newColumn: [ :mainColumn | mainColumn newRow: [ :nameRow | nameRow add: #labelName; add: #textName ] height: 25. mainColumn newRow: [ :titleRow | titleRow add: #labelTitle; newRow: [ :titleRadioRow | titleRadioRow add: #radioMr; add: #radioMrs; add: #radioMs ] ] height: 25. mainColumn newRow: [ :buttonRow | buttonRow add: #buttonGreet ] height: 25 ]; yourself /code Am I doing it right? Another feature is: debuggerSpec spec: #default ^ SpecLayout composed add: #inspector withSpec: #debuggerSpec; yourself #inspector being the instance variable name that holds a subclass of ComposableModel that defines class side #debuggerSpec, which answers a SpecLayout. Does this mean that for every table cell I have to create a new class? Not sure if this helped. All of these questions are for your tutorials ? 2013/11/7 Bahman Movaqar bah...@bahmanm.com Hi all, Is it possible to nest layouts in Spec? For example can I combine `SpecColumnLayout` and `SpecRowLayout` together? -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Spec - Tutorial Series
Really nice tutorial :) If I were you, I would based it on Pharo 3.0 more than 2.0. Why ? Because your tutorial will be outdated quite soon (in a couple on months) when 3.0 will be released. Our you could try to use the latest Spec version at least since the one shipped in 2.0 is old and out-dated :P But it’s always cool to see people writing things about my work :) Once again, really nice tuto, and I like the way you write, keep going :) Ben On 07 Nov 2013, at 16:01, b...@openinworld.com wrote: Bahman Movaqar wrote: Hi all, I'm writing a series of tutorials for Spec for beginners like myself and I'd really appreciate any input on the material. The first episode is done: http://www.bahmanm.com/blogs/spec-part-1-basics Thanks Bahman. I like your writing style and theme. The code snippets are well presented. What platform is your blog hosted on? Some feedback... --- Not sure if you should be prompting people to dirty the Spec package by using example category Spec-Tutorial. Even though there is currently no such a package, one day there might be. Perhaps using category My-Spec-Tutorial would be better alternative. further radio buttons setup is done in setupTitleRadioButtons: looks like it should lose the colon at the end of the method name - An alternative to the nested IF statements in MyFirstWindowuserTitle... If you extend RadioButtonGroup with... RadioButtonGroupselected ^buttons detect: [:b | b state ]. and add instance variable 'radioButtonGroup' to MyFirstWindow and in MyFirstWindowsetupTitleRadioButtons do radioButtonGroup := RadioButtonGroup new then you could have... MyFirstWindowuserTitle ^ radioButtonGroup selected label Then again, for someone completely new to Smalltalk, the nested IF statements might be more familiar. So perhaps leave that part as it is, then describe how to refactor the code to be more 'Pharo' like. You might say... at the time I did this, the RadioButtonGroup class was missing a method to return the selected button, but it was simple to extend the library with the following Note that I tested this on Pharo3, but I expect Pharo 2 would be the same for this case. cheers -ben
Re: [Pharo-users] Spec - Nested Layouts
About table, I have an example which will be running soon in Pharo (the changes are waiting to be integrated)tree := TreeModel new.tree openWithSpec.tree columns: (Array with: (TreeColumnModel new displayBlock: [:node | node content first asString ]; headerLabel: 'Name'; yourself) with: (TreeColumnModel new displayBlock: [:node | node content second asString ]; headerLabel: 'Last Name'; yourself) with: (TreeColumnModel new displayBlock: [:node | node content third asString ]; headerLabel: 'Age'; yourself) with: (TreeColumnModel new displayBlock: [:node | node content fourth asString ]; headerLabel: 'Gender'; yourself)). tree roots: { {'Benjamin'.'Van Ryseghem'.'26'.'M'}. {'Pamela'.'Anderson'.'Far too much'.'F'}}Will produceRight now, you can get the same by - adding MorphTreeAdapter#columns: columns: columns self widgetDo: [ :w |w columns: columns.w resizerChanged.w updateList ]And then evaluating:tree := TreeModel new.tree openWithSpec.tree columns: (Array with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item first asString asMorph ]; headerButtonLabel: 'Name' font: nil; yourself) with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item second asString asMorph ]; headerButtonLabel: 'Last Name' font: nil; yourself) with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item third asString asMorph ]; headerButtonLabel: 'Age' font: nil; yourself) with: (MorphTreeColumn new rowMorphGetSelector: [:node | node item fourth asString asMorph ]; headerButtonLabel: 'Gender' font: nil; yourself)). tree roots: { {'Benjamin'.'Van Ryseghem'.'26'.'M'}. {'Pamela'.'Anderson'.'Far too much'.'F'}}
Ben
On 07 Nov 2013, at 15:54, Clément Bera bera.clem...@gmail.com wrote:2013/11/7 Benjamin benjamin.vanryseghem.ph...@gmail.com
Just a general remark: you should try as much as possible to avoid hard coding width/height :)
there are some methods on ComposableModel you could use like buttonHeight toolbarHeight etc. that you should use instead :)
Ben
On 07 Nov 2013, at 13:22, Bahman Movaqar bah...@bahmanm.com wrote:
On 11/07/2013 12:45, Clément Bera
wrote:
Hey,
I don't know what you want exactly.
You can do:
spec
spec
^ SpecLayout composed
newRow:
[:row |
row
newColumn: [ :col |
col
add:
#list width: 135;
add:
#description ] ];
yourself
and nest that as many times as you want (but I don't know
if this was your question).
I just tried this one and it works (see the code below) BUT, the
code is so hard to read and understand just for 3 rows and 7
widgets!
code
defaultSpec
^ SpecLayout composed
newColumn: [ :mainColumn |
mainColumn
newRow: [ :nameRow |
nameRow
add: #labelName;
add: #textName ]
height: 25.
mainColumn
newRow: [ :titleRow |
titleRow
add: #labelTitle;
newRow: [ :titleRadioRow |
titleRadioRow
add: #radioMr;
add: #radioMrs;
add: #radioMs ] ]
height: 25.
mainColumn newRow: [ :buttonRow | buttonRow add:
#buttonGreet ] height: 25 ];
yourself
/code
Am I doing it right? I guess this is right. But I think you need to generate this layout out of collections, not to write it.
Another feature is:
debuggerSpec
spec:
#default
^
SpecLayout composed
add:
#inspector withSpec: #debuggerSpec;
yourself
#inspector being the instance variable name that holds a
subclass of ComposableModel that defines class side
#debuggerSpec, which answers a SpecLayout.
Does this mean that for every table cell I have to create a new
class?Yeah well I was just pointing out all the choices you had. Depending on what you want to do you could have a class hierarchy similar to this:
SpecTableAbstractSpecColumn SpecColumnA SpecColumnBAbstractSpecCell SpecCellA SpecCellBSpecTable having column, column having cells.
But this may not be the best choice.Now that you caught my interest, I tried to do a table. I put it in attachment the result. It is a .st file, so drag and drop it in your image, then click file in entire file. Then try to run 'SpecTable new', it opens a table with 3 columns and 5 rows, with no complex layout method. All the code is in SpecTable (Cmd+f,Cmd+c to find a class in nautilus or write the class name in workspace then select
