- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ListModel Menu

by Guillermo Polito

Hi Jonathan, If you check users of MenuModel and ListModel in the image, you get a few results that could give you an idea of how to do it. For example: If you look for users of MenuModel you arrive to EpSelection>>filtersSubMenu, which will lead you to EpSelection>>populateMenu: aMenu. And this leads you to: EpSelection >> initializeItemsModel itemsModel multiSelection: true; displayBlock: [ :item | item asMorph ]; childrenBlock: [ :item | self childrenItemsOf: item ]; whenSelectedItemsChanged: [ :selectedItems | self refreshEntryContentModelWith: selectedItems. itemsModel menu: [ :aMenu | self selection populateMenu: aMenu ] ]. So apparently, the method #menu: receives a block with a menu as argument, and you have to populate it with elements. Another way to arrive to the same conclusion is to look for senders of #menu:. There you see for example: ChangeSorterApplication >> initializeWidgets ... methodsListModel menu: [:menu :shifted | self messageMenu: menu shifted: shifted ]. changesListModel menu: [:aMenu :shifted | self changeSetMenu: aMenu shifted: shifted ]. classesListModel menu: [:aMenu :shifted | self classMenu: aMenu shifted: shifted ]. ... Cheers, Guille On Mon, Apr 3, 2017 at 6:44 PM, Jonathan Khalil <jonathan(a)esp.sn> wrote: > I did it perfectly with a toolbar. > > Jonathan > > 2017-04-03 16:16 GMT+02:00 Jonathan Khalil <jonathan(a)esp.sn>: > >> Hello, >> >> I am testing the MenuModel and ListModel widgets. I wanted to create a >> popup menu and then set it with the ListModel >> menu: method. It runs >> right but once the listmodel open, when i right click on one item to see >> the pop-up menu it gives me the error as in the "#error.png" picture. >> Here is my example test (based on not significant data): >> >> [ >> >> menu := MenuModel new. >> menu addGroup: [ :group | >> group addItem: [ :item | >> item name: 'item1'; >> icon: (self iconNamed: #nautilus); >> action: [ anyAction1 ]]]; >> addGroup: [ :group | >> group addItem: [ :item | >> item name: 'item2'; >> icon: (self iconNamed: #smallSaveAs); >> action: [ anyAction2 ]]]; >> addGroup: [ :group | >> group addItem: [ :item | >> item name: 'item3'; >> icon: (self iconNamed: #smallAuthoringTools); >> action: [ anyAction4 ]]]. >> ll := LinkedList new. >> ll add: 'value1'; >> add: 'value2'; >> add: 'value3'; >> add: 'value4'; >> add: 'value5'; >> yourself. >> lm := ListModel new. >> lm >> items: ll; >> title: 'ListModel Menu Test'. >> *lm menu:menu.* >> lm openWithSpec. >> >> ] >> >> I get that the #cull:cull: message is not understood by my instance of >> MenuModel but i simply call the #menu: method defined in ListModel. Any >> ideas on the problem ? >> > >

April 4, 2017

Survey about the Roassal visualization engine

by Alexandre Bergel

Hi! We are doing a survey about Roassal. Giving about 2 minutes of your time to fill the survey can have a tremendous impact on it. https://goo.gl/forms/zEt7VdkLSYvBG6jf2 Help us improving Roassal :-) The Object Profile team

April 3, 2017

Re: [Pharo-dev] Glamour Fast List selection bug or incorrect usage?

by Andrei Chis

Hi, That's actually the default behavior, but I see there is also a bug. Normally if you want to allow deselection in a presentation you should use allowDeselection. Just I see there is a bug in the fast table renderer because if I add #allowDeselection to the first presentation when clicking again on the selected element the selection port is not cleared. If you use #list instead of #fastList it works. I think you can get the desired behaviur using this code: ----------------------------------------------------------------- tabulator := GLMTabulator new. tabulator column: #one; column: #two; column: #three. tabulator transmit to: #one; andShow: [ :composite | composite list allowDeselection; display: [ :x | Array with: x ] ]. tabulator transmit to: #two; andShow: [ :composite | composite list allowDeselection; display: [ :x | Array with: 2 * x ] ]. tabulator transmit from: #one; to: #three; from: #two; to: #three; transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ]; andShow: [ :a | a fastList display: [ :x | Array with: x ] ]. tabulator openOn: 4. ----------------------------------------------------------------- Cheers, Andrei On Mon, Apr 3, 2017 at 9:35 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi! > > If you create the following Glamour browser: > > ``` > tabulator := GLMTabulator new. > > tabulator column: #one; column: #two; column: #three. > > tabulator transmit to: #one; andShow: [ :composite | > composite fastList display: [ :x | Array with: x ] ]. > tabulator transmit to: #two; andShow: [ :composite | > composite fastList display: [ :x | Array with: 2 * x ] ]. > > tabulator transmit from: #one; to: #three; andShow: [ :a | > a fastList display: [ :x | Array with: x ] ]. > tabulator transmit from: #two; to: #three; andShow: [ :a | > a fastList display: [ :x | Array with: x ] ]. > > tabulator openOn: 4. > ``` > > You will get the following browser: > > > if you then select 4, the third list appears. If you then select 8, the > value is changed: > > > But since then, the third list does not change. It stays with 8 value > forever. > > Do I miss something? Should I define it differently? > Or if it is a bug: Can you give me insights how to fix it? > > Tested in the latest Pharo 6. > > Thanks! > Juraj > >

April 3, 2017

Glamour Fast List selection bug or incorrect usage?

by Juraj Kubelka

Hi! If you create the following Glamour browser: ``` tabulator := GLMTabulator new. tabulator column: #one; column: #two; column: #three. tabulator transmit to: #one; andShow: [ :composite | composite fastList display: [ :x | Array with: x ] ]. tabulator transmit to: #two; andShow: [ :composite | composite fastList display: [ :x | Array with: 2 * x ] ]. tabulator transmit from: #one; to: #three; andShow: [ :a | a fastList display: [ :x | Array with: x ] ]. tabulator transmit from: #two; to: #three; andShow: [ :a | a fastList display: [ :x | Array with: x ] ]. tabulator openOn: 4. ``` You will get the following browser: if you then select 4, the third list appears. If you then select 8, the value is changed: But since then, the third list does not change. It stays with 8 value forever. Do I miss something? Should I define it differently? Or if it is a bug: Can you give me insights how to fix it? Tested in the latest Pharo 6. Thanks! Juraj

April 3, 2017

Re: [Pharo-dev] ListModel Menu

by Jonathan Khalil

I did it perfectly with a toolbar. Jonathan 2017-04-03 16:16 GMT+02:00 Jonathan Khalil <jonathan(a)esp.sn>: > Hello, > > I am testing the MenuModel and ListModel widgets. I wanted to create a > popup menu and then set it with the ListModel >> menu: method. It runs > right but once the listmodel open, when i right click on one item to see > the pop-up menu it gives me the error as in the "#error.png" picture. > Here is my example test (based on not significant data): > > [ > > menu := MenuModel new. > menu addGroup: [ :group | > group addItem: [ :item | > item name: 'item1'; > icon: (self iconNamed: #nautilus); > action: [ anyAction1 ]]]; > addGroup: [ :group | > group addItem: [ :item | > item name: 'item2'; > icon: (self iconNamed: #smallSaveAs); > action: [ anyAction2 ]]]; > addGroup: [ :group | > group addItem: [ :item | > item name: 'item3'; > icon: (self iconNamed: #smallAuthoringTools); > action: [ anyAction4 ]]]. > ll := LinkedList new. > ll add: 'value1'; > add: 'value2'; > add: 'value3'; > add: 'value4'; > add: 'value5'; > yourself. > lm := ListModel new. > lm > items: ll; > title: 'ListModel Menu Test'. > *lm menu:menu.* > lm openWithSpec. > > ] > > I get that the #cull:cull: message is not understood by my instance of > MenuModel but i simply call the #menu: method defined in ListModel. Any > ideas on the problem ? >

April 3, 2017

ListModel Menu

by Jonathan Khalil

Hello, I am testing the MenuModel and ListModel widgets. I wanted to create a popup menu and then set it with the ListModel >> menu: method. It runs right but once the listmodel open, when i right click on one item to see the pop-up menu it gives me the error as in the "#error.png" picture. Here is my example test (based on not significant data): [ menu := MenuModel new. menu addGroup: [ :group | group addItem: [ :item | item name: 'item1'; icon: (self iconNamed: #nautilus); action: [ anyAction1 ]]]; addGroup: [ :group | group addItem: [ :item | item name: 'item2'; icon: (self iconNamed: #smallSaveAs); action: [ anyAction2 ]]]; addGroup: [ :group | group addItem: [ :item | item name: 'item3'; icon: (self iconNamed: #smallAuthoringTools); action: [ anyAction4 ]]]. ll := LinkedList new. ll add: 'value1'; add: 'value2'; add: 'value3'; add: 'value4'; add: 'value5'; yourself. lm := ListModel new. lm items: ll; title: 'ListModel Menu Test'. *lm menu:menu.* lm openWithSpec. ] I get that the #cull:cull: message is not understood by my instance of MenuModel but i simply call the #menu: method defined in ListModel. Any ideas on the problem ?

April 3, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Pavel Krivanek

2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hello, > > This are the things I believe still needs to be solved to be able to > release Pharo 6.0: > > VM: > === > - win32, cairo fonts problem (I submitted a new VM to test, I think this > is fixed :P) > - make all tests pass (there are still some failing tests when compiling a > new VM)/. > - libgit2: Still not there, Jan and Ben were trying and sent some > suggestions but I still didnât had the time to test it. > > Image: > ===== > > - iceberg still needs to go inside the image, Iâm running to release > version 0.4 (maybe this week?) and then we can integrate. > - I'm still convinced there is a leak. I need to check this in detail. And > of course some help on thisâ¦ Pavel?â¦ would be cool :) > I will definitely help but I need more information :-) -- Pavel > > List is a lot smaller now :) > If everything goes well, we can target to release next week. > > Next: > - Test the new process and tape some videos explaining how we will > contribute with a bootstrapped process using github :) > > cheers! > Esteban >

April 3, 2017

Re: [Pharo-dev] unable to start linked vm file (linux)

by Esteban Lorenzano

script may be broken for 64bits. I need to take a lookâ¦ you can still start the binary directly, as a workaround. Esteban > On 3 Apr 2017, at 15:35, John Brant <brant(a)refactoryworkers.com> wrote: > > I'm unable to start a linked vm file (ln). I have several vm's, and I link to the one that I want to use. However, it appears that this no longer works. With the April 3rd threaded vm on http://files.pharo.org/vm/pharo-spur64/linux/, I get the following error when it tries to start: > > ldd: ./lib/pharo/5.0-201704030814/pharo: No such file or directory > Error. Could not determine platform's libc path for VM. > Try forcing $PLATFORMLIBDIR in ./pharo, based on LIBC_SO. > Please report what works to pharo [vm-dev] mail list. > LIBC_SO= > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 > DISTRIB_CODENAME=xenial > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" > NAME="Ubuntu" > VERSION="16.04.2 LTS (Xenial Xerus)" > ID=ubuntu > ID_LIKE=debian > PRETTY_NAME="Ubuntu 16.04.2 LTS" > VERSION_ID="16.04" > VERSION_CODENAME=xenial > UBUNTU_CODENAME=xenial > UNAME=Linux p5810.refactoryworkers.com 4.4.0-71-generic #92-Ubuntu SMP Fri Mar 24 12:59:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > System seems to be 64 bit. You may need to (re)install the 32-bit libraries. > > This worked for the March 10th vm. > > > John Brant >

April 3, 2017

unable to start linked vm file (linux)

by John Brant

I'm unable to start a linked vm file (ln). I have several vm's, and I link to the one that I want to use. However, it appears that this no longer works. With the April 3rd threaded vm on http://files.pharo.org/vm/pharo-spur64/linux/, I get the following error when it tries to start: ldd: ./lib/pharo/5.0-201704030814/pharo: No such file or directory Error. Could not determine platform's libc path for VM. Try forcing $PLATFORMLIBDIR in ./pharo, based on LIBC_SO. Please report what works to pharo [vm-dev] mail list. LIBC_SO= DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" NAME="Ubuntu" VERSION="16.04.2 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.2 LTS" VERSION_ID="16.04" VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial UNAME=Linux p5810.refactoryworkers.com 4.4.0-71-generic #92-Ubuntu SMP Fri Mar 24 12:59:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux System seems to be 64 bit. You may need to (re)install the 32-bit libraries. This worked for the March 10th vm. John Brant

April 3, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Peter Uhnak

Thank you Esteban! I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :) (I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself). Thanks! Peter On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote: > Hi Peter, > > I think I fixed the problem, can you try latest vm? > > Esteban > > > > On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > Peter I took the latest mac VM and Moose 6.1 and I used your example > > then I played during 15 min with all the roassal examples and I cannot reproduce > > but I'm on mac. > > > > > > > > On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > > Tx peter! > > I really really sorry for this state of affair. > > I would like to tell you that I thank you for all the feedback you sent. Please continue. > > I imagine what it is to get a system that blow up under your fingers. > > I'm always trying to work with the alpha version (because I attract bugs) > > I got some crashes playing with roassal - but I updated to the latest vm and trying. > > > > Can you sync with esteban so that he can access your setup? And yes we are burning > > esteban on this.... We should pay attention that our faery does not get too exhausted :). > > > > Stef > > > > > > On Fri, Mar 31, 2017 at 1:10 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > > > > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. > > > > So, all this discussion is informative, but the mail that originates it can be reviewed :) > > > > No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts... > > > > I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text > > > > v := RTView new. > > v add: (RTLabel new elementOn: '-_-'). > > v > > > > <fml.png> > > â > > > > Or running AthensSurfaceExamples class>>exampleDrawText > > > > <fml_squared.png> > > > > > > In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this. > > > > Peter > > > > > > > > Esteban > > > > > >> On 29 Mar 2017, at 14:43, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > >> > >> We cannot work in 5.0 professionally with the VM released at the time. > >> I am also using an intermediate VM thing to do the job. > >> > >> That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point. > >> > >> Phil > >> > >> On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> > >> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > >> > > >> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: > >> >> wellâ¦ > >> >> > >> >> Latest VM is intended to work with latest Pharo, not with older versions. > >> >> Latest VM is *always* an experimental/unstable VM that needs to be consideredâ¦ that, experimental and unstable. Otherwise there would not be point on having the distinction between stable/latest, isnât? > >> >> > >> > > >> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 Alphaâ). > >> >> > >> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for Pharo 5â. > >> >> > >> >> Of course, you can live at the edge, but that doesnât means something is broken when something fails if premises are not fulfilled :) > >> > > >> > Well considering VM for Pharo 5 never worked for me properly, whether it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have a choice but to use the latest. If there is a better way then I am all ears, constantly dealing with crashing VM when I need to get work done is extremely frustrating... > >> > > >> > Also I was under the impression that newer VM should work with older images, with the only exception being Cog/Spur change. Or should I have six different VMs and Pharo Launcher with six different VM configurations? > >> > >> we moved the paradigm a couple of years ago: each Pharo version comes with his own VM version (Other smalltalks do that too). > >> Being infinite backward compatible is a lot of pain :) > >> > >> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for PharoLauncher: you ship with latest stable but you can always download newers or olders (this is not yet implemented, is just a requirement I addedâ¦ well, couple of years ago when we changed the way we wanted VMs to work). > >> > >> Esteban > >> > >> > > >> > Peter > >> > > >> >> > >> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may happen, since this is all alfa :P) > >> >> > >> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will work, but if that works, ONCE we move latest vm to stable status we can consider backporting it to Pharo 5. > >> >> > >> >> Esteban > >> >> > >> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > >> >>> > >> >>> The new "fixed" compactor VM has broken FT... > >> >>> > >> >>> So any text drawn on Athens canvas results in red cross... > >> >>> > >> >>> Error in... > >> >>> > >> >>> CairoFontFace class>>primFtFace:loadFlags: > >> >>> > >> >>> 'Unable to find function address' > >> >>> > >> >>> Apparently because someone renamed libfreetype-6.dll to libfreetype.dll > >> >>> > >> >>> (Windows VM latest, Pharo 5) > >> >>> > >> >> > >> >> > >> > > >> > >> > >> > > > > > > > > >

April 3, 2017