November 2013 - Pharo-users

Re: [Pharo-users] How images can be loaded

by Sven Van Caekenberghe

Hi Ronie, On 22 Nov 2013, at 19:00, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hello, > > I would like to know how I could load .png image into pharo, and being able to access to their pixel data for manipulation or display it. > > Greetings, > Ronie Salgado Here is an example: '/Users/Sven/Desktop/test.jpg' asFileReference readStreamDo: [ :in | (JPEGReadWriter on: in) nextImage asMorph openInWindow ]. Inspect the results of #nextImage or #asMorph to learn more, this code actually opens the image in a window in Pharo. Regards, Sven

Nov. 22, 2013

How images can be loaded

by Ronie Salgado

Hello, I would like to know how I could load .png image into pharo, and being able to access to their pixel data for manipulation or display it. Greetings, Ronie Salgado

Nov. 22, 2013

Re: [Pharo-users] Writing a GUI - Where to start?

by Johan Fabry

On Nov 22, 2013, at 12:35 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> About Glamour, isn'it used to create Browser? How can i create a typical window? > > What is a typical window? Spec gives too much freedom and not enough > structure for 'typicalâ applications. > > Almost every window in your smalltalk system is a browser. > Nearly all would be significantly less code when build with Glamour. I agree with Stephan that it is less code to write a browser-like user interface with Glamour. That is the advantage of using a domain-specific solution, like Glamour. However if you are writing something that falls outside of the domain, i.e. a user interface that is not a browser, it will become difficult with Glamour. So I also agree that the question is: what do you mean with 'a typical window'? What is it that your UI should do ? ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Nov. 22, 2013

Re: [Pharo-users] Writing a GUI - Where to start?

by Stephan Eggermont

>About Glamour, isn'it used to create Browser? How can i create a typical window? What is a typical window? Spec gives too much freedom and not enough structure for 'typicalâ applications. Almost every window in your smalltalk system is a browser. Nearly all would be significantly less code when build with Glamour. Stephan

Nov. 22, 2013

[launcher] templates from fixed URLs

by btc＠openinworld.com

Hi Damien, I like the PhLFixedURLsTemplateGroup you just added to directly reference specific urls like Pharo 3.0 latest. I corrected a problem with Settings. Also I think its useful to be explicit about the ones that refer to 'latest' so I made that change. Could you review these. The next great thing would be to allow users to add their own fixed urls without coding. btw, I was going to follow your example to change PhLTemplateGroupRepository>>refreshLocal to >>refreshFast but it seems the only sender is itself, and also inserted breakpoints do not trigger. Looks like it is surplus to requirements. cheers -ben

Nov. 22, 2013

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

by Igor Stasenko

So, here the changes which should work (but i didn't tested). And being on your place, i would get rid of FMOD_SYSTEM class, because you can just subclass FmodSystem from NBExternalObject directly (and use it in signatures) and so it will be holding the handle, and naturally work as a representation of external entity. Also note that in this case FmodSystem is alias to C FMOD_SYSTEM* so, for every function which expects FMOD_SYSTEM*, you should just use FmodSystem, and if it expects FMOD_SYSTEM**, you using FmodSystem* basically, same as if you would have: typedef FmodSystem FMOD_SYSTEM*; in C. On 22 November 2013 15:10, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 22 November 2013 05:09, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Igor Stasenko wrote >> >> The better way is to subclass from NBExternalObject then >> > which made exactly for such purposes, by holding an opaque handle to >> > something (you don't care what is inside), and simplifies a lot of >> things. >> >> I made "NBExternalObject subclass: #FMOD_SYSTEM". >> I then tried to use it via: >> system := FMOD_SYSTEM new. >> err := self System_CreateNBExternalObject: system. >> With callout: >> ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(NBExternalObject >> system)). >> >> For the argument type in the signature, for good measure I tried: >> 1. NBExternalObject >> 2. FMOD_SYSTEM >> 3. NBExternalAddress >> All three with zero, one, and two *'s after. The only one that didn't >> report >> some variety of "An instance of Xyz expected" was >> "FMOD_System_Create(FMOD_SYSTEM system)" for which the library returns an >> invalid argument error code. >> >> yet again, you miss the right solution: you must pass a pointer to where > value will be stored > (since function doing exactly that). > > so you should do it like: > 1. "NBExternalObject subclass: #FMOD_SYSTEM". > > 2. method to call the function will look like following: > create: system > ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(FMOD_SYSTEM * system)). > > 3. and call it like following: > > system := FMOD_SYSTEM new. > self handleError: (self create: system) ifOk: [ ^ system ] > > 3a. optionally, you want want to initialize it just after you know that > you obtained correct handle, > to do that, you could do following: > > FMOD_SYSTEM class>>new > | system | > system := super new. > self handleError: (self create: system) ifOk: [ ^ self newWithHandle: > system handle ] > > and newWithHandle: could look something like following: > > newWithHandle: aHandle > > system := super basicNew. > system handle: aHandle. > ^ system initialize > > (because it is important to set the handle first, like that you can > actually initialize something more > by using it, which you logically do, just after creating a new handle. > and note you must not call 'super initialize' then, because it will reset > handle.) > and i'm sure you can find more elegant solution :) > > btw if anyone wants to play with it: >> 1. >> Gofer it >> smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; >> package: 'FMOD'; >> load. >> >> 2. Download the FMOD library for your platform: >> - windows - >> >> http://www.fmod.org/download/fmodstudio/api/Win/fmodstudioapi10208win-insta… >> - Mac - >> >> http://www.fmod.org/download/fmodstudio/api/Mac/fmodstudioapi10208mac-insta… >> >> 3. Copy the library to "FileLocator imageDirectory / 'FMOD Programmers >> API/api/lowlevel/lib/libfmod.dylib'" >> >> The working example is: >> | sound | >> sound := FmodSound fromFile: '/path/to/file.mp3' asFileReference. >> [ sound play ] fork. >> >> The broken one described above is: "FMOD exampleNBExternalObject." >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Nov. 22, 2013

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

by Igor Stasenko

On 22 November 2013 05:09, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Igor Stasenko wrote > >> The better way is to subclass from NBExternalObject then > > which made exactly for such purposes, by holding an opaque handle to > > something (you don't care what is inside), and simplifies a lot of > things. > > I made "NBExternalObject subclass: #FMOD_SYSTEM". > I then tried to use it via: > system := FMOD_SYSTEM new. > err := self System_CreateNBExternalObject: system. > With callout: > ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(NBExternalObject > system)). > > For the argument type in the signature, for good measure I tried: > 1. NBExternalObject > 2. FMOD_SYSTEM > 3. NBExternalAddress > All three with zero, one, and two *'s after. The only one that didn't > report > some variety of "An instance of Xyz expected" was > "FMOD_System_Create(FMOD_SYSTEM system)" for which the library returns an > invalid argument error code. > > yet again, you miss the right solution: you must pass a pointer to where value will be stored (since function doing exactly that). so you should do it like: 1. "NBExternalObject subclass: #FMOD_SYSTEM". 2. method to call the function will look like following: create: system ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(FMOD_SYSTEM * system)). 3. and call it like following: system := FMOD_SYSTEM new. self handleError: (self create: system) ifOk: [ ^ system ] 3a. optionally, you want want to initialize it just after you know that you obtained correct handle, to do that, you could do following: FMOD_SYSTEM class>>new | system | system := super new. self handleError: (self create: system) ifOk: [ ^ self newWithHandle: system handle ] and newWithHandle: could look something like following: newWithHandle: aHandle system := super basicNew. system handle: aHandle. ^ system initialize (because it is important to set the handle first, like that you can actually initialize something more by using it, which you logically do, just after creating a new handle. and note you must not call 'super initialize' then, because it will reset handle.) and i'm sure you can find more elegant solution :) btw if anyone wants to play with it: > 1. > Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; > package: 'FMOD'; > load. > > 2. Download the FMOD library for your platform: > - windows - > > http://www.fmod.org/download/fmodstudio/api/Win/fmodstudioapi10208win-insta… > - Mac - > > http://www.fmod.org/download/fmodstudio/api/Mac/fmodstudioapi10208mac-insta… > > 3. Copy the library to "FileLocator imageDirectory / 'FMOD Programmers > API/api/lowlevel/lib/libfmod.dylib'" > > The working example is: > | sound | > sound := FmodSound fromFile: '/path/to/file.mp3' asFileReference. > [ sound play ] fork. > > The broken one described above is: "FMOD exampleNBExternalObject." > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko.

Nov. 22, 2013

Re: [Pharo-users] How to combine Pharo Desktop and Seaside?

by btc＠openinworld.com

Hi & welcome. I'm not in a position to help directly, but just suggest that the more specific advice the advice you are seeking, the more use it is to paste here the specific code you have defined and the specific Workspace snippets you are executing. This reduces the chance for misunderstanding. Also while you may only know enough to ask about "X", someone looking at your code might be able to advise that you should really be asking about "Y" and here is its answer "Z". The code you paste should be reduced to the minimal self contained app that highlights your need. hope things are well with you, cheers -ben steliosgan wrote: > First of all...Thank you all for the instant response (ÎÏÏÎ±ÏÎ¹ÏÏÏ ÏÎ±ÏÏÎ¹ÏÏÎ·). > I would like more precise directions as I am soooo new at this. I have the > Pharo app, which returns an OrderedCollection. I created a class PrintHtml > (inherents from WAComponent) with an instance variable in which I bind the > ordered collection. Then, in workspace, I am trying to create an object for > each of these classes, but in PrintHtml renderContentsOn: html, the instance > variable looks undefined. I hope that you understand my problem. :D > > > > -- > View this message in context: http://forum.world.st/How-to-combine-Pharo-Desktop-and-Seaside-tp4724166p47… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Nov. 22, 2013

How to combine Pharo Desktop and Seaside?

by Torsten Bergmann

You can initialize your instance variable in an initialize method WAComponent subclass: #PrintHtml instanceVariableNames: 'tasks' classVariableNames: '' poolDictionaries: '' category: 'KillerApp-Web-UI' Then a method to initialize on the instance side PrintHtml>>initialize: initialize "initialize the receiver" super initialize. tasks := #('read' 'before' 'you' 'try') If you send #new to a class this #initialize method is automatically called. If you do not want it use #basicNew. So if you enter PrintHtml new in a workspace and select "Inspect it" to open an inspector on the new object this method gets called and therfore you will see that the instance variable should have the collection as contents. Side note: Do not forget the "super initialize" in this method - otherwise superclass initialization for seaside components is not done. Then use a normal rendering method to display the ivar in the browser renderContentOn: html html orderedList list: tasks If I understand you correctly you want to know how you acces the Seaside generated code for a WAComponent subclass also in a workspace. This is easy: |component| component := PrintHtml new. "your seaside component" WARenderCanvas builder render: [ :html | html render: component ] which should return the generated HTML: '<ol><li>read</li><li>before</li><li>you</li><li>try</li></ol>' now. That is one way. The preferred way for Seasiders is to directly look at the generated HTML code in the webbrowser. Just go to your app: http://localhost:8080/killerapp Down at the bottom you will find the seaside development toolbar (only visible when developing) and then click on "Halo". Now Seaside renders a rectangle around each component and you can click on "Source" to Switch to the source of a component. Also try the other buttons there. For sure you should read one of the introduction stuff on Seaside, I would recommend the online Seaside book: http://book.seaside.st/book Bye T.

Nov. 22, 2013

Re: [Pharo-users] Writing a GUI - Where to start?

by prova email

About Glamour, isn'it used to create Browser? How can i create a typical window? > From: stephan(a)stack.nl > Date: Fri, 22 Nov 2013 12:39:06 +0100 > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Writing a GUI - Where to start? > > Johan wrote: > >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. > > Iâd recommend to try to build your application with Glamour first. Only if that doesnât provide a good fit, > take a look at spec. Spec is much more powerful, but too low level for most applications. > > Stephan > > > > >

Nov. 22, 2013