- Pharo-dev - lists.pharo.org

[Pharo-project] How to recognize a method "inherited" from a trait
by Noury Bouraqadi June 14, 2011

June 14, 2011

Hi, How does the browser recognizes that some selector in a class is inherited from a Trait to display it in italic? Thanx, Noury

2 3

Re: [Pharo-project] WindowOrganiser (was: Tab widget improvements)
by laurent laffont June 14, 2011

June 14, 2011

Hi Gary, I've played a little and changed: DockingBarMorph subclass: #WindowOrganiser uses: TEasilyThemed instanceVariableNames: 'tabGroup' classVariableNames: '' poolDictionaries: '' category: 'Guru' (sorry, I feel stupid, I don't know how to make a changeset, need to look at this :) So I can open a sort of docking panel: (see attached screenshot) WindowOrganiser new openInWorld; height:200; adhereToBottom. That means we can have docking panels like the IDEs Java students use :) Moreover TWM tile windows only in clear area, so all this play nicely together. I wonder what's the best way to package all this. In Polymorph ? Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st On Thu, Jun 9, 2011 at 3:33 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Even better when working more properly (attached) > > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Thursday, June 09, 2011 2:12 PM > *Subject:* Re: [Pharo-project] Tab widget improvements > > > On Thu, Jun 9, 2011 at 3:01 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > >> Something to get you started... ;-0 >> > > > aaaaargggggggg THAT'S SO DAMN COOOOOOOOOOOOOOOOOOL > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Laurent > > > > >> >> WindowOrganiser new open >> >> Optionally, via halo, turn on "Accept drops" for the window, else use the >> window menu to "Grab window...". >> >> Plenty of evilness left to sort out with it, naturally. >> Have fun! >> >> Regards, Gary >> >> ----- Original Message ----- >> *From:* Gary Chambers <gazzaguru2(a)btinternet.com> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Sent:* Thursday, June 09, 2011 10:03 AM >> *Subject:* Re: [Pharo-project] Tab widget improvements >> >> Hi Laurent. >> >> Sounds like a cool idea and is possible. You'd likely need to modify >> SystemWindow somewhat to deal with being within a tab (remove grips, >> forward label changes to the tab, handle activation (TopWindow stuff might >> be tricky) etc.). You'd also want an option (perhaps a button in the tab >> label) to break the window out again. >> >> For some of this you could get some ideas from StandardWindow with respect >> to fullscreen, #noteNewOwner: >> >> Regards, Gary >> >> ----- Original Message ----- >> *From:* laurent laffont <laurent.laffont(a)gmail.com> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Sent:* Wednesday, June 08, 2011 5:20 PM >> *Subject:* Re: [Pharo-project] Tab widget improvements >> >> Hi Gary, >> >> I wanted to try what follows while coding TWM, maybe with your magic super >> powers its easy :) >> >> Create a SystemWindow subclass: #TabbedWindow (or better name). >> >> In this window's menu there's the list of all other SystemWindows. When >> you click on it, the window goes as tab. >> >> So I can group several windows in a tabbed container. Like the group >> windows feature of KDE. See >> http://blip.tv/sebastian-kgler/window-managing-features-in-kde-plasma-4-4-3… at >> 1'50. >> >> Is it hard ? Idea how to do this ? >> >> Laurent. >> >> >> On Wed, Jun 8, 2011 at 4:57 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: >> >>> For another example, just a quickly hacked together (i.e. quick and >>> dirty) multi workspace thing attached. >>> >>> MultiWorkspaceWindow new open >>> >>> Use the window menu to add workspaces, otherwise works like a workspace >>> for the selected tab. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Gary Chambers" < >>> gazzaguru2(a)btinternet.com> >>> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Wednesday, June 08, 2011 3:26 PM >>> >>> Subject: Re: [Pharo-project] Tab widget improvements >>> >>> >>> Lol >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Wednesday, June 08, 2011 3:19 PM >>>> Subject: Re: [Pharo-project] Tab widget improvements >>>> >>>> >>>> You know my soft spot :) >>>> >>>> Doru >>>> >>>> >>>> On 8 Jun 2011, at 16:04, Gary Chambers wrote: >>>> >>>> I expect Doru will want it in 1.3 for Moose ;-) >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- From: "Marcus Denker" < >>>>> marcus.denker(a)inria.fr> >>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Wednesday, June 08, 2011 3:00 PM >>>>> Subject: Re: [Pharo-project] Tab widget improvements >>>>> >>>>> >>>>> >>>>> On Jun 8, 2011, at 3:55 PM, Gary Chambers wrote: >>>>> >>>>> Attached, some improvements to the TabGroupMorph etc. having had >>>>>> feedback from Doru. >>>>>> >>>>>> Provides scrolling buttons when insufficient room for all tabs and >>>>>> displays only tabs for which there is room! (excepting at least one). >>>>>> >>>>>> Can optionally set wrapScrolling on the TabSelectorMorph to allow >>>>>> wraparound scrolling via the buttons. >>>>>> >>>>>> >>>>> Do we put that in 1.3 or 1.4? >>>>> >>>>> http://code.google.com/p/pharo/issues/list?thanks=4376 >>>>> >>>>> >>>>> -- >>>>> Marcus Denker -- http://www.marcusdenker.de >>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Live like you mean it." >>>> >>>> >>>> >>>> >> >

4 19

[Pharo-project] Fuel version 1.4 uses #isBinary, and SIXX uses #tab:
by Yanni Chiu June 14, 2011

June 14, 2011

FLBufferedWriteStream>>sizeBuffer: calls #isBinary, which is not currently implemented by FSWriteStream - probably because #isBinary is not specified by ANSI. Is there a reason why the stream is not always binary? Also, when using SIXX with FSWriteStream, I had to add the non-ANSI #tab: method to FSWriteStream. There's probably a dozen calls to #tab: in the SIXX code. Should #tab: be added to FSWriteStream somehow? Maybe a non-ANSI streams extension package?

3 5

[Pharo-project] [update 1.3] #13264
by Marcus Denker June 14, 2011

June 14, 2011

13264 ----- Issue 4402: SimpleCodeLoader http://code.google.com/p/pharo/issues/detail?id=4402 Issue 4403: safer default text style http://code.google.com/p/pharo/issues/detail?id=4403 Issue 4400: ProgressBarEnabled http://code.google.com/p/pharo/issues/detail?id=4400 Issue 3107: UserInterruptHandler >> handleEvent: is dependent on SoundService http://code.google.com/p/pharo/issues/detail?id=3107 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-project] [squeak-dev] Morphic on HTML+CSS
by Janko MivÅ¡ek June 14, 2011

June 14, 2011

S, info(a)tomsik.cz piÅ¡e: > I am no squeak/pharo/cuis master, > > but in my opinion the best approach is still "objects as servers" > - no matter what html6 will be able to do, it won't be enough. > > however html5+js means we can leverage ajax - and provide illusion > of objects as servers - and that's cool. > > so: > > 1. yes > 2. not sure, I'd rather spend energy on something different. Remember that we the web guys are spending energy close to that goal for quite a while already. The Iliad/Aida (bit less Seaside) component model is close to what Morphic is, as far I know Morphic. And with Jtalk we can cover JavaScript from Smalltalk code too. Add the open-source and portable WebKit [1] based foundation like many web browsers have and we are there! So, if we point ourselves to this direction, for sure someone will come with a courage to experiment in approximately this way: - WebKit based foundation - Iliad/Aida component model adopted to Morphic on top - Jtalk for running JavaScript from Smalltalk - Squeak/Pharo image with more or less unchanged tools So, we switch one level higher in running Squeak/Pharo GUI: from bare operating system's graphic/windowing support to WebKit based HTML5/CSS/JavaScript one. With HTML5 Canvas and WebGL for HW optimized graphics,... Janko [1] http://www.webkit.org/ > On Tue, 14 Jun 2011 13:41:45 +0200, Janko MivÅ¡ek > <janko.mivsek(a)eranova.si> wrote: > >> Hi all, >> >> In light of recent Microsoft surprising U-turn announcement [1] that in >> Windows 8 it swithes to HTML5 (HTML5+CSS+JavaScript) instead of .NET+WPF >> and Silverlight for desktop app development it is IMO a right time to >> think about: >> >> 1. is this a clear signal that HTML5 for ALL apps, both desktop and the >> web is inevitable? >> 2. is this a clear signal that we need to rebuild Morphic on top of >> HTML+CSS, to leverage all Morphic advantages and come back >> to bleeding edge again? >> >> I think yes. What Squeak/Pharo/Cuis GUI masters say? >> >> Best regards >> Janko >> >> [1] >> http://arstechnica.com/microsoft/news/2011/06/html5-centric-windows-8-leave… >> -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

[Pharo-project] Morphic on HTML+CSS
by Torsten Bergmann June 14, 2011

June 14, 2011

Not only .NET ... also JavaFX 2.0 is using CSS for skinning: http://download.oracle.com/javafx/2.0/css_tutorial/jfxpub-css_tutorial.htm Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

[Pharo-project] [update 1.3] #13263
by Marcus Denker June 14, 2011

June 14, 2011

13263 ----- Issue 4398: saveImageInNewContext http://code.google.com/p/pharo/issues/detail?id=4398 Issue 4395: ChangeSet class>>#fileIntoNewChangeSet: dependent on Compression http://code.google.com/p/pharo/issues/detail?id=4395 Issue 4397: FileStream class>>#fileIn: dependent on Compression http://code.google.com/p/pharo/issues/detail?id=4397 Issue 4396: DeepCopier warnIverNotCopiedIn:sel: and tools http://code.google.com/p/pharo/issues/detail?id=4396 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 2

Re: [Pharo-project] Toward MVP
by Schwab,Wilhelm K June 14, 2011

June 14, 2011

Attached is code to produce something I need. It shows a list of items; click one and the text goes into the box below the list. The user can also type into that box; there is no sense of responsibility about saving the user's work. The mind set is that the list provides most things of interest, and it should be possible to "say anything" just in case. Click the button, and the text in the bottom field goes into a log file, complete with time stamp. It's not big deal, but neither should be creating it. Start with a model: EventLogger>>initialize super initialize. quickList := ListModel new list:#( 'Start' 'BP down' 'BP up' 'End' '***SNAFU***' ); yourself. fileSequence := ... "the log" Add the attached code. Among the important features are transparent handling of the selection index for the list and having something (following Dolphin, call them presenters) between the model and views (morphs). Models should not know or care about their selection index; the morph/view should do that (in Pharo, the ListPresenter is the natural home for it), and can do so in a way that "just works" for most purposes. The text presenters have been more trouble than I expected, but they bring with them some very important concepts. Dolphin's ViewResource is looking for a home (whether it will find one is open for bets), and the volley of events between model, view and presenter is starting to appear. Among the important tests (not yet realized as unit tests - sorry) is one model with multiple views; change the model and the views update. Dolphin's layout managers are very powerful, and while the pieces to make them exist in Pharo, I have yet to master their use. A common trap is to use top-level views when something composable is possible and desirable. I am not yet sure what to do about that. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, June 04, 2011 3:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. On Jun 4, 2011, at 6:55 PM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for the homework assignments :) > > I have not specifically looked at simple grid in 1.3, but I will do so - gotta go for a run first. > > My MVP code is not yet available, but I intend to release it once it is remotely worth having. I was pleasantly surprised to find more than I thought I had working. Maybe I should soon put a "first draft" where people can see it. yes please do :) > The design (if that word applies<g>) is a compromise between Dolphin's approach to GUIs where it makes sense to follow them, realizing that the Dolphin view composer isn't here, some "going along with the flow" where Polymorph makes things too easy to ignore, and finally some Seaside influence. > > Dolphin uses a GUI to assemble views. I am planning to do that with code, but ultimately that should not be forced. It will take some time to balance all of that. > >>> did you check HPI library or void nullpointer widgets? > > I am not familiar with them, but I will look. I suspect I am finding smoke screens on HPI, I think that they have some nice widgets to get inspired from. > but the null pointer widgets look like I found what you have in mind. It looks like you are "thinking big," which is great. I am not a big believer that native widgets equate to speed, but, there are times when some native code goes a LONG way in that direction. I would like to see us able to use one native window per tool shell, if not be able to go completely native. I think it would be painful, but ultimately good for us. I'm not talking about native. just getting some good foundation. > > Short term, I am not so much thinking of replacing the GUI (though my stuff would hopefully run on top of any widgets - with some work) as I am with reducing the redundant work that goes in to a GUI, and moving us toward MVP. The latter is for two reasons: (1) it is a nice framework; (2) I have a lot of old code that I would like to see have a home on Linux. yes work on it and let us see it. > > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, June 04, 2011 12:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. > > On Jun 4, 2011, at 6:08 PM, Schwab,Wilhelm K wrote: > >> I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations. >> >> ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why? > > > did you check on 1.3 because igor and ben spent some time optimizing it a bit. > >> I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time. > > > I'm interested in that MVP framework. > Do you have some code somewhere? > > With igor we discussed about killing pluggable.... but for now one step at the time. > > >> The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason? > > did you check HPI library or void nullpointer widgets? > > I would love to have a gorup of people pushing that. >> >> Bill >> >> >> >> >> > > >

2 1

Re: [Pharo-project] [Pharo-users] Pharo on Fedora 15_64
by Mariano Martinez Peck June 13, 2011

June 13, 2011

On Sat, Jun 11, 2011 at 10:13 PM, <bblochl(a)arcor.de> wrote: > I actually installed Fedora 15 with GNOME 3 on a AMD-64 a couple of days > back and tried to run Pharo, latest stable version and ran into some > problem: > > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ ./Pharo.sh > ./Pharo.sh: > /home/bb/Pharo/Pharo-1.2.1-CogOneClick.app/Contents/Linux/squeakvm: > /lib/ld-linux.so.2: bad ELF interpreter: Datei oder Verzeichnis nicht > gefunden > ./Pharo.sh: Zeile 16: > /home/bb/Pharo/Pharo-1.2.1-CogOneClick.app/Contents/Linux/squeakvm: Erfolg > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ ldd `which ls` > alias: > ldd: ./alias: Datei oder Verzeichnis nicht gefunden > ls='ls: > ldd: ./ls='ls: Datei oder Verzeichnis nicht gefunden > --color=auto': > ldd: ./--color=auto': Datei oder Verzeichnis nicht gefunden > /bin/ls: > linux-vdso.so.1 => (0x00007fffc7bc8000) > libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003761400000) > librt.so.1 => /lib64/librt.so.1 (0x00007f5c7914b000) > libcap.so.2 => /lib64/libcap.so.2 (0x0000003764400000) > libacl.so.1 => /lib64/libacl.so.1 (0x000000376e800000) > libc.so.6 => /lib64/libc.so.6 (0x00007f5c78db1000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f5c78bac000) > /lib64/ld-linux-x86-64.so.2 (0x00007f5c79367000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5c78991000) > libattr.so.1 => /lib64/libattr.so.1 (0x000000376a800000) > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ readelf -l a.out > bash: readelf: command not found... > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ > > What to do now?? > > Regards > > B. Blochl > > -- Mariano http://marianopeck.wordpress.com

3 2

[Pharo-project] [update 1.3] #13262
by Marcus Denker June 13, 2011

June 13, 2011

13262 ----- Issue 4393: Move CrLfFileStream to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=4393 Issue 4392: move Utilities and Preferences from Deprecated12 to Compatibility package http://code.google.com/p/pharo/issues/detail?id=4392 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0