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

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

by Hilaire Fernandes

Thanks Markus for the feedback. Hilaire Le 04/04/2014 10:09, Marcus Denker a Ã©crit : > Soâ¦ yes, right now there are no Preferences. But we can add them back. > (I can do that). > > The only thin that will (right now) not work is decompiling, but just running > a program is fine. If you want to debug you need sources+changes. > > This is not nice and we will fix that with Pharo4. -- Dr. Geo http://drgeo.eu

April 4, 2014

Re: [Pharo-users] JPEG support in Artifact

by olivier auverlot

Hi Stephan, Yes, we have discussed with Guillaume. We don't have a better solution to propose but we will be really interested if someone write a portable JPEG support. It will be cool to have the possibility to extract header informations from pictures without using a plugin. Best regards 2014-04-03 16:02 GMT+02:00 Guillaume Larcheveque < guillaume.larcheveque(a)gmail.com>: > 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 4, 2014

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

by Goubier Thierry

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

April 4, 2014

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

by MartinW

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. 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? :) -- 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 4, 2014

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

by MartinW

Goubier Thierry wrote > Yes, I've seen that. It's fine by me that the list displayed in the > widget is copied and sorted, just that I would have liked to be able to > touch the true collection hidden inside the ListModel. Unless the list > model is more like a ListAdaptor in meaning, in which cas I'll know that > I have to build better objects around it. > > But then, as that example shows, I then have problem connecting the drag > and drop to the model. > >> Then for the convenient methods, I am not that sure :P >> But maybe itâs a good use case for traits :P > > I'd say it depends what a ListModel is. Is this a model, in which case > I'd like it to stand for the abstract collection inside and be able to > add and remove items in it (and not use the trick of l1 items: l1 > getItems), or is this just an adapter? If an adapter, then drag and drop > is hard to implement. Yes exactly. I just naively tried it, without knowing if it was made for this purpose. But i wanted to be able to touch the real collections behind the ListModels and also the real object behind the drag-operation, not only it's string representation. So the user could drag around things between lists and the real objects would get added/removed to the real collections represented by those lists. In the next step i would also have wanted objects represented on the screen by a simple textlabel to be dragged and dropped on any list and then be added to the collection represented by this particular list. -- 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 4, 2014

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

by Goubier Thierry

Le 04/04/2014 10:41, Benjamin a Ã©crit : > Why not, but this will not solve the issue :) > I will probably fix that in the train today (5h long trip to Bordeaux ^^) > . I'm nice to give you something to do during those 5 hours, then ;) > 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 :) Yes, I've seen that. It's fine by me that the list displayed in the widget is copied and sorted, just that I would have liked to be able to touch the true collection hidden inside the ListModel. Unless the list model is more like a ListAdaptor in meaning, in which cas I'll know that I have to build better objects around it. But then, as that example shows, I then have problem connecting the drag and drop to the model. > Then for the convenient methods, I am not that sure :P > But maybe itâs a good use case for traits :P I'd say it depends what a ListModel is. Is this a model, in which case I'd like it to stand for the abstract collection inside and be able to add and remove items in it (and not use the trick of l1 items: l1 getItems), or is this just an adapter? If an adapter, then drag and drop is hard to implement. 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] Drag and drop items between list views

by Benjamin

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.goubier(a)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 <wm(a)fastmail.fm <mailto:wm@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. >> >> > > -- > 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 Benjamin

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

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

by Marcus Denker

On 03 Apr 2014, at 19:05, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > 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. > Soâ¦ yes, right now there are no Preferences. But we can add them back. (I can do that). The only thin that will (right now) not work is decompiling, but just running a program is fine. If you want to debug you need sources+changes. This is not nice and we will fix that with Pharo4. > I guess this situation can evolve in future. > Yes! Marcus

April 4, 2014

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

by Goubier Thierry

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 <wm(a)fastmail.fm <mailto:wm@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. > > -- 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