April 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Drag and drop items between list views

by Goubier Thierry

Le 03/04/2014 22:55, MartinW a Ã©crit : > 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. :( I believe what is happening is that ListModel and the widget above convert your Collectible instance into a string to display it; and then the drag and drop code forget to get the model object behind the displayed string (i.e. the drag and drop code expect all items to be morphs with all sort of complex stuff). 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. > 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. 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

April 4, 2014

Re: [Pharo-users] Few questions about Spec (instance specific layout and skinning)

by Thomas Bany

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.sysdev(a)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.sysdev(a)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. >> > >

April 3, 2014

Re: [Pharo-users] Drag and drop items between list views

by Benjamin Van Ryseghem

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 <wm(a)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-tp4752285p4752… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 3, 2014

Re: [Pharo-users] Drag and drop items between list views

by MartinW

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-tp4752285p4752… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 3, 2014

Re: [Pharo-users] Few questions about Spec (instance specific layout and skinning)

by Thomas Bany

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.sysdev(a)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. >

April 3, 2014

Re: [Pharo-users] changes and sources file availability

by Hilaire Fernandes

Hi, It is gone. And for me it is a very annoying. Now if you want the system to prevent looking I am afraid you have to modify some system class method as there is no more hook to do it properly (see the mailing list archive for discussion about that a few weeks ago). Then I don't know the consequence of Pharo3 running without the source files. Some feedback will be nice on that specific point. I guess this situation can evolve in future. Hilaire Le 02/04/2014 13:12, Usman Bhatti a Ã©crit : > Hello, > > In Pharo 2.0, we could enforce the image not to look for sources and > changes file at the startup with: > > SmalltalkImage > checkChangesFileAvailability: false; > checkSourcesFileAvailability: false. > > I could not found these selectors anymore in my Pharo 3.0 image. > > Clement mentioned to me a while ago that it was due to the change of > compiler (Opal) and it might not be safe to remove these files (if I > remember correctly). So, my question: > > 1/ Can I remove these two files safely from my production image? > 2/ If the answer to 1/ is yes, how can I tell my image not to look for > these files at image startup? > > tx, > Usman -- Dr. Geo http://drgeo.eu

April 3, 2014

Re: [Pharo-users] Few questions about Spec (instance specific layout and skinning)

by Thomas Bany

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.

April 3, 2014

Re: [Pharo-users] Complex spec example

by Ben Coman

April 3, 2014

Re: [Pharo-users] Complex spec example

by Damien Cassou

On Thu, Apr 3, 2014 at 1:28 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Is there a rather complex example available that uses spec. I mean a sort of a complex UI that solves some real use cases from where I can steal ideas and patterns how things are done. I'm just a UI noop and like to have all the guidance available :) the Pharo Launcher for example. It's not too complex though -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

April 3, 2014

Re: [Pharo-users] JPEG support in Artifact

by Guillaume Larcheveque

If I remember well, we used this way to get some data about image required by PDF format. Maybe there is a smarter way to do this, I will have a look with Olivier about this. 2014-04-03 10:32 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > Reg Krock took a look at how difficult it would be to port Artefact to > Gemstone. > He found that JPEG support uses a plugin based reader/writer, and seems to > render the JPEG using BitBlt and Form. > > Why are JPEGs rendered? I'd think embedding them should be enough > (and be better for speed and image quality) > > Stephan > -- *Guillaume Larcheveque*

April 3, 2014