Re: [Pharo-dev] We need *you* for the upcoming Pharo's website

2014-04-22 Thread Max Leske

On 22.04.2014, at 00:16, Sven Van Caekenberghe s...@stfx.eu wrote:

 
 On 21 Apr 2014, at 22:51, Max Leske maxle...@gmail.com wrote:
 
 
 On 21.04.2014, at 22:09, Sven Van Caekenberghe s...@stfx.eu wrote:
 
 Nice one, why not add a file browser as well ?
 
 Sure, maybe the text then needs a small update:
 
 stack serialization with fuel.txt
 
 Argh, I didn't see the text the first time; your explanation with the 
 dragdrop makes the file browser (less/not) necessary.

:p 

No problem. Now the description is more complete.

 
 pharo-3-external-stack.png
 
 
 On 20 Apr 2014, at 12:09, Max Leske maxle...@gmail.com wrote:
 
 Screen Shot 2014-04-20 at 11.57.52.pngstack serialization with fuel.txt
 On 15.04.2014, at 13:03, Damien Cassou damien.cas...@gmail.com wrote:
 
 Hi everyone,
 
 we are working on a new website for Pharo! We need your help. If you
 have some time, please create and send us one of the following items:
 
 - An up-to-date screenshot of Pharo 3.0 that shows some cool features.
 It should be 800px wide ;
 - A screencast ;
 - A paragraph (around 40 words) that presents a nice topic about Pharo
 and a corresponding screenshot.
 
 We will select 1 large screenshot, 3 screencasts and 4 topic paragraphs.
 
 This could be a very nice way for you to contribute to Pharo!
 
 Best,
 
 -- 
 Damien Cassou
 http://damiencassou.seasidehosting.st
 
 Success is the ability to go from one failure to another without
 losing enthusiasm.
 Winston Churchill
 
 
 
 
 
 




Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread Nicolas Cellier
2014-04-22 6:30 GMT+02:00 Tudor Girba tu...@tudorgirba.com:

 One question is why do still have the disable free type fonts option?
 This was useful when free type was still in development, but I think now
 it is no longer useful.
 Or are there still use cases for it?

 Doru



At the risk of repeating myself (that's maybe 10 times I say it here, but
it's like shouting in the desert...) ,
freetype is pretty inefficient because it displays characters one by one
(call a primitive foreach and every character).
So if you are on a not so fast device, strike fonts are still a good option
because the primitive displays groups of characters in a batch.
So please, please, please, for once before breaking things that works and
replacing them by a thing that works only partially,
do it the other way around:
- first make it fully work (that means add a new freetype primitive
displaying batch of chars)
- then drop any historical bits you want

Of course, you are free to completely drop support for slow machines, but
it must be consciously.


 On Mon, Apr 21, 2014 at 7:32 PM, stepharo steph...@free.fr wrote:

 Hi

 when freetype is on do you think that it makes sense to have strikeFont
 proposed as default fonts? Like it is done right now, I get bitmapVera
 even if I
 want to see FreeType fonts.

 Stef




 --
 www.tudorgirba.com

 Every thing has its own flow



Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread Tudor Girba
Hi,

I think my message generated a misunderstanding.

I am not arguing for dropping of bitmap fonts at all. I am only arguing for
removing the option of not having freetype. People on slow devices will
still be able to use the bitmap fonts.

Is that wrong?

Cheers,
Doru



On Tue, Apr 22, 2014 at 9:09 AM, Nicolas Cellier 
nicolas.cellier.aka.n...@gmail.com wrote:


 2014-04-22 6:30 GMT+02:00 Tudor Girba tu...@tudorgirba.com:

 One question is why do still have the disable free type fonts option?
 This was useful when free type was still in development, but I think now
 it is no longer useful.
 Or are there still use cases for it?

 Doru



 At the risk of repeating myself (that's maybe 10 times I say it here, but
 it's like shouting in the desert...) ,
 freetype is pretty inefficient because it displays characters one by one
 (call a primitive foreach and every character).
 So if you are on a not so fast device, strike fonts are still a good
 option because the primitive displays groups of characters in a batch.
 So please, please, please, for once before breaking things that works and
 replacing them by a thing that works only partially,
 do it the other way around:
 - first make it fully work (that means add a new freetype primitive
 displaying batch of chars)
 - then drop any historical bits you want

 Of course, you are free to completely drop support for slow machines, but
 it must be consciously.


 On Mon, Apr 21, 2014 at 7:32 PM, stepharo steph...@free.fr wrote:

 Hi

 when freetype is on do you think that it makes sense to have strikeFont
 proposed as default fonts? Like it is done right now, I get bitmapVera
 even if I
 want to see FreeType fonts.

 Stef




 --
 www.tudorgirba.com

 Every thing has its own flow





-- 
www.tudorgirba.com

Every thing has its own flow


[Pharo-dev] updated documentation on magritte?

2014-04-22 Thread Esteban Lorenzano
Hi, 

is there an updated documentation on magritte? where can I find it?

cheers, 
Esteban



[Pharo-dev] Pharo success story for Issys Tracking broken?

2014-04-22 Thread Torsten Bergmann

http://www.pharo-project.org/about/success-stories
includes a story about scaling seaside.

Unfortunately none of the links work. Any infos on that?



[Pharo-dev] Messages reported as spam by Gmail

2014-04-22 Thread kilon alios
Please note that I found two threads reported as spam in my spam folder.
One was about a competition for Roassal to create a visualisation with it
and the second one was about a finder bug, both have not recieved any
replies since then so this issue does not affect just me.

So make sure you check your spam folder from time to time to ensure that
people that ask questions get a reply and not get lost in other people spam
folders assuming that people ignore them or that their questions are too
stupid.


Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread Sergi Reyner
2014-04-22 8:21 GMT+01:00 Tudor Girba tu...@tudorgirba.com:

 I am not arguing for dropping of bitmap fonts at all. I am only arguing
 for removing the option of not having freetype. People on slow devices will
 still be able to use the bitmap fonts.

 Is that wrong?


Well, look at it this way: who should be able to have the final word on
what side of the speed/prettiness dichotomy Pharo should be: the user or
the system?

Cheers,
Sergi


Re: [Pharo-dev] updated documentation on magritte?

2014-04-22 Thread Sean P. DeNigris
EstebanLM wrote
 is there an updated documentation on magritte? where can I find it?

I didn't find any. I was referencing a combination of the original papers,
and slides I found online about the differences in Magritte 3. For Morphic,
I implemented as I needed features, so there is none :/



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/updated-documentation-on-magritte-tp4755692p4755740.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Pharo success story for Issys Tracking broken?

2014-04-22 Thread Sean P. DeNigris
Torsten Bergmann wrote
 Unfortunately none of the links work. Any infos on that?

I did a little googling and checked the wayback machine; didn't come up with
anything relevant...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Pharo-success-story-for-Issys-Tracking-broken-tp4755704p4755742.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



[Pharo-dev] Lost in spec

2014-04-22 Thread Igor Stasenko
i want to use different adaptor for TextModel, when opening my UI
so that when widget is built for it, it will be my own widget,
not PluggableTextMorph..

but i found it hard to do.. here what i tried:


I try to replace bindings, so at the stage when spec interpreted, it uses
my bindings:

openWithSpec

| old result |
old := SpecInterpreter bindings.

SpecInterpreter bindings: TxAdapterBindings new.

[ result :=  super openWithSpec ]
ensure: [ SpecInterpreter bindings: old ].
^ result


in TxAdapterBindings i initialize it same as morphic bindging, except from
text model binding:
 #TextAdapter= #TxTextAdapter

but it is never invoked nor used :(

i understand the overall model, but it seems like not completely,
(else the above trick would work).. what do i miss?

-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] Pillar in TextMate

2014-04-22 Thread Damien Cassou
On Sun, Apr 20, 2014 at 8:35 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:

 I'm happy to announce that I've created a small bundle for TextMate. You can 
 find it here: https://github.com/Uko/Pillar.tmbundle

 Also I've exported it to ATOM (new editor from github) package, but it's 
 crappy because ATOM lacks some stuff right not. Package is called: 
 language-pillar, source is here: https://github.com/Uko/language-pillar


great job Yuriy, thanks. I referenced both from
https://github.com/DamienCassou/pillar-documentation

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another without
losing enthusiasm.
Winston Churchill



Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread Tudor Girba
I do not see what this has to do with anything.

Right now we are offering the possibility to not be able to load FreeType
fonts and this leads to buggy behavior when the user starts playing with
that toggle.

I fail to see why we need the option in the first place. All I am saying is
that we should remove the option from the settings browser and simply have
the freetype fonts enable all the time. This means that you will still be
able to load the bitmap fonts without problems just like before.

And it is our (as builders of Pharo) responsibilities to design. The user
can say if he likes it or not and in our case can even try to contribute.
But, this does not take the design responsibility from our shoulders.

Doru


On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner sergi.rey...@gmail.comwrote:

 2014-04-22 8:21 GMT+01:00 Tudor Girba tu...@tudorgirba.com:

 I am not arguing for dropping of bitmap fonts at all. I am only arguing
 for removing the option of not having freetype. People on slow devices will
 still be able to use the bitmap fonts.

 Is that wrong?


 Well, look at it this way: who should be able to have the final word on
 what side of the speed/prettiness dichotomy Pharo should be: the user or
 the system?

 Cheers,
 Sergi




-- 
www.tudorgirba.com

Every thing has its own flow


Re: [Pharo-dev] WhatsUp from: 2014-04-21 until: 2014-04-30

2014-04-22 Thread Damien Cassou
### Here's what I've been up to since the last WhatsUp:

- fixed Pharo bugs for the 3.0 release
- worked a lot on Marina, a new CMS based on Pillar, Tide and Amber
(https://github.com/tide-framework/marina)

### What's next, until 2014-04-30 (*):

- python parsing


-- 
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another without
losing enthusiasm.
Winston Churchill



Re: [Pharo-dev] Phexample: Image Destroying Bug

2014-04-22 Thread Sean P. DeNigris
Sean P. DeNigris wrote
 ...In 3.0, it never returns, creating an more and more debugger processes
 until the image becomes unresponsive.

This broke with 30808
http://forum.world.st/pharo-project-pharo-core-447842-30808-td4752289.html :
Log Message: 
  --- 
  30808 
13156 EyeInspector does not automatically refresh its list 
https://pharo.fogbugz.com/f/cases/13156

13163 Splitters move more morphs that needed 
https://pharo.fogbugz.com/f/cases/13163

Any ideas?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Phexample-Image-Destroying-Bug-tp4755253p4755774.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Phexample: Image Destroying Bug

2014-04-22 Thread Sean P. DeNigris
Sean P. DeNigris wrote
 13156 EyeInspector does not automatically refresh its list 
 https://pharo.fogbugz.com/f/cases/13156

This is the culprit. Loading into 30807 gives the broken behavior.

Here's a snippet of the call chain:
MultiByteFileStream(WriteStream)space
EyeInspector(Object)longPrintOn:limitedTo:indent: in Block: [ :title
:index | ...
Array(SequenceableCollection)withIndexDo:
Array(SequenceableCollection)doWithIndex:
EyeInspector(Object)longPrintOn:limitedTo:indent:




-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Phexample-Image-Destroying-Bug-tp4755253p4755775.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



[Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread roberto.mine...@usi.ch
Hi,

I am wondering if there is the possibility to get milliseconds in a TimeStamp.

I need to record fine-grained events and second-granularity is not enough.

Cheers,
Roberto


Re: [Pharo-dev] Pharo success story for Issys Tracking broken?

2014-04-22 Thread Marcus Denker

On 22 Apr 2014, at 13:53, Sean P. DeNigris s...@clipperadams.com wrote:

 Torsten Bergmann wrote
 Unfortunately none of the links work. Any infos on that?
 
 I did a little googling and checked the wayback machine; didn't come up with
 anything relevant…
 

I have removed the article for now… 

Marcus




Re: [Pharo-dev] Phexample: Image Destroying Bug

2014-04-22 Thread Sean P. DeNigris
Problem found and fix proposed in new thread - Phexample: API Change
Proposal (was Phexample: Image Destroying Bug)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Phexample-Image-Destroying-Bug-tp4755253p4755786.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



[Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

2014-04-22 Thread Sean P. DeNigris
Reverting EyeInspector#updateList revealed the error when Phexample is used
in latest Pharo 3.0...

PhexMatcher uses #= as part of it's DSL e.g. 1 should = 1. Because it
doesn't respond normally to #=, #hash is implemented to signal an error
(self error: 'Don''t put a matcher into a dictionary. It does not behave
ordinarily on ='). I guess the receiver inspector on the bottom left of the
debugger keeps the items in a dictionary, so #hash gets called and
everything blows up.

The first thought that comes to my mind is that #= is too cute as a DSL.
#= is too deep of a smalltalk concept to justify hijacking, AFAICT to avoid
writing equals:.

I removed #= and #hash from PhexMatcher, adding an #equals: with the former
#= implementation, and everything seems to work.

I don't have write access to
http://smalltalkhub.com/mc/Phexample/Phexample/main/ and realize it's a big
API change, so I committed the fix to
http://smalltalkhub.com/mc/SeanDeNigris/SeansOutbox/main/ :
Name: Phexample-SeanDeNigris.71

MAJOR API CHANGE:
- change matcher #= to #equal: e.g. 1 should = 1 would now be written 1
should equal: 1
- update all code to use new API

Motivation: the #= magic made it impossible to store matchers in
dictionaries, and #hash was implemented to signal an error explaining as
much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts,
and are assumed to work as expected. In Pharo 3.0, the debugger tried to put
matchers in a dictionary, causing an infinite error loop whenever a matcher
failed.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Destroying-Bug-tp4755787.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



[Pharo-dev] Smalltalk Hub on Chrome

2014-04-22 Thread Sean P. DeNigris
I noticed sometimes sthub hangs forever on Chrome (Version 34.0.1847.116 on
Mavericks), but if I open it alongside in Safari, it loads fine...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread Yuriy Tymchuk
Well, it has #asNanoSeconds, how finer can you go?

Uko

On 22 Apr 2014, at 17:13, roberto.mine...@usi.ch wrote:

 Hi,
 
 I am wondering if there is the possibility to get milliseconds in a TimeStamp.
 
 I need to record fine-grained events and second-granularity is not enough.
 
 Cheers,
 Roberto




Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

2014-04-22 Thread Stefan Marr
Hi Sean:

First of all, I enabled public write access on the repository.
While I am the admin on the project, I took it over from Niko and Adrian, and 
at this point, I would consider it ‘community maintained’.

The rest inline:

On 22 Apr 2014, at 16:40, Sean P. DeNigris s...@clipperadams.com wrote:

 - change matcher #= to #equal: e.g. 1 should = 1 would now be written 1
 should equal: 1
 
 Motivation: the #= magic made it impossible to store matchers in
 dictionaries, and #hash was implemented to signal an error explaining as
 much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts,
 and are assumed to work as expected. In Pharo 3.0, the debugger tried to put
 matchers in a dictionary, causing an infinite error loop whenever a matcher
 failed.

I personally don’t have a qualified opinion, in the sense that I do not 
actively use Phexample at the moment.
Still, I will state it anyway: I don’t like the change.

So, just for the sake of argument, are there other ways?
Are matchers reused, or are they one-shot things?
If the later is true, perhaps, we could maintain the ‘cuteness’ of #= by making 
the matchers a little more cooperative?
If they are one-shot objects, how about using their standard behavior only on 
the first access, and then switch their state so that #= and #hash respond 
normally?

Thanks
Stefan



-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/






Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread roberto.mine...@usi.ch
TimeStamp now rounds the timestamp, so #asNanoSeconds returns the seconds * 
10e9.

Doing “DateAndTime now” solves my issue, but this is a total non-sense.

Cheers,
R

On Apr 22, 2014, at 4:54 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:

 Well, it has #asNanoSeconds, how finer can you go?
 
 Uko
 
 On 22 Apr 2014, at 17:13, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am wondering if there is the possibility to get milliseconds in a 
 TimeStamp.
 
 I need to record fine-grained events and second-granularity is not enough.
 
 Cheers,
 Roberto
 
 




Re: [Pharo-dev] Smalltalk Hub on Chrome

2014-04-22 Thread Nicolas Petton

Sean P. DeNigris writes:

 I noticed sometimes sthub hangs forever on Chrome (Version 34.0.1847.116 on
 Mavericks), but if I open it alongside in Safari, it loads fine...

Does the page load but stays without content, or is it another issue?

Nico




 -
 Cheers,
 Sean
 --
 View this message in context: 
 http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788.html
 Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


-- 
Nicolas Petton
http://nicolas-petton.fr



[Pharo-dev] Versionner screencast

2014-04-22 Thread Christophe Demarey
Hello,

I made a small screencast on Versionner to explain how to use it: 
https://www.youtube.com/watch?v=S5Dbmmln8tA

Regards,
Christophe.

smime.p7s
Description: S/MIME cryptographic signature


Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread Sven Van Caekenberghe
TimeStamp is deprecated, because it creates too much confusion, you better use 
DateAndTime.

On 22 Apr 2014, at 17:11, roberto.mine...@usi.ch wrote:

 TimeStamp now rounds the timestamp, so #asNanoSeconds returns the seconds * 
 10e9.
 
 Doing “DateAndTime now” solves my issue, but this is a total non-sense.
 
 Cheers,
 R
 
 On Apr 22, 2014, at 4:54 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
 
 Well, it has #asNanoSeconds, how finer can you go?
 
 Uko
 
 On 22 Apr 2014, at 17:13, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am wondering if there is the possibility to get milliseconds in a 
 TimeStamp.
 
 I need to record fine-grained events and second-granularity is not enough.
 
 Cheers,
 Roberto
 
 
 
 




Re: [Pharo-dev] updated documentation on magritte?

2014-04-22 Thread stepharo

Not that I know.
I started a chapter on the pharo for the entreprise (with the idea to 
base it on the seaside book) but I need help.

If you start writing a draft I will do a pass.

Stef

On 22/4/14 09:28, Esteban Lorenzano wrote:

Hi,

is there an updated documentation on magritte? where can I find it?

cheers,
Esteban







Re: [Pharo-dev] Lost in spec

2014-04-22 Thread stepharo

Igor where is your code so that I can give a try?


On 22/4/14 13:56, Igor Stasenko wrote:

i want to use different adaptor for TextModel, when opening my UI
so that when widget is built for it, it will be my own widget,
not PluggableTextMorph..

but i found it hard to do.. here what i tried:


I try to replace bindings, so at the stage when spec interpreted, it 
uses my bindings:


openWithSpec

| old result |
old := SpecInterpreter bindings.

SpecInterpreter bindings: TxAdapterBindings new.

[ result :=  super openWithSpec ]
ensure: [ SpecInterpreter bindings: old ].
^ result


in TxAdapterBindings i initialize it same as morphic bindging, except 
from text model binding:

 #TextAdapter= #TxTextAdapter

but it is never invoked nor used :(

i understand the overall model, but it seems like not completely,
(else the above trick would work).. what do i miss?

--
Best regards,
Igor Stasenko.





Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread roberto.mine...@usi.ch
If done right, TimeStamp would have not caused any confusion. 
Now that I discovered that a TimeStamp is a DateAndTime with rounded seconds 
(read: non-sense) I agree with you.

On Apr 22, 2014, at 6:42 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 TimeStamp is deprecated, because it creates too much confusion, you better 
 use DateAndTime.
 
 On 22 Apr 2014, at 17:11, roberto.mine...@usi.ch wrote:
 
 TimeStamp now rounds the timestamp, so #asNanoSeconds returns the seconds 
 * 10e9.
 
 Doing “DateAndTime now” solves my issue, but this is a total non-sense.
 
 Cheers,
 R
 
 On Apr 22, 2014, at 4:54 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
 
 Well, it has #asNanoSeconds, how finer can you go?
 
 Uko
 
 On 22 Apr 2014, at 17:13, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am wondering if there is the possibility to get milliseconds in a 
 TimeStamp.
 
 I need to record fine-grained events and second-granularity is not enough.
 
 Cheers,
 Roberto
 
 
 
 
 
 




Re: [Pharo-dev] Lost in spec

2014-04-22 Thread Igor Stasenko
TxText-Athens-IgorStasenko.27 (TxText on smalltalkhub)
just committed

see TxApplicationWithToolbar


TxApplicationWithToolbar new openWithSpec
etc



On 22 April 2014 20:21, stepharo steph...@free.fr wrote:

 Igor where is your code so that I can give a try?



 On 22/4/14 13:56, Igor Stasenko wrote:

 i want to use different adaptor for TextModel, when opening my UI
 so that when widget is built for it, it will be my own widget,
 not PluggableTextMorph..

 but i found it hard to do.. here what i tried:


 I try to replace bindings, so at the stage when spec interpreted, it uses
 my bindings:

 openWithSpec

 | old result |
 old := SpecInterpreter bindings.

 SpecInterpreter bindings: TxAdapterBindings new.

 [ result :=  super openWithSpec ]
 ensure: [ SpecInterpreter bindings: old ].
 ^ result


 in TxAdapterBindings i initialize it same as morphic bindging, except
 from text model binding:
  #TextAdapter= #TxTextAdapter

 but it is never invoked nor used :(

 i understand the overall model, but it seems like not completely,
 (else the above trick would work).. what do i miss?

 --
 Best regards,
 Igor Stasenko.






-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] Confused by NewListExample

2014-04-22 Thread Stephan Eggermont
- title toggling doesn’t work
- doesn’t have a usable size
- window title not set
- dragging doesn’t work
- disallows selection in one place,
  allows it somewhere else
- menu the same on list title
- uses halts directly instead of 
  calling a method on self displaying 
  the action (open a dialog, show a growl)




Re: [Pharo-dev] Lost in spec

2014-04-22 Thread Nicolai Hess
2014-04-22 13:56 GMT+02:00 Igor Stasenko siguc...@gmail.com:

 i want to use different adaptor for TextModel, when opening my UI
 so that when widget is built for it, it will be my own widget,
 not PluggableTextMorph..

 but i found it hard to do.. here what i tried:


 I try to replace bindings, so at the stage when spec interpreted, it uses
 my bindings:

 openWithSpec

 | old result |
 old := SpecInterpreter bindings.

 SpecInterpreter bindings: TxAdapterBindings new.

 [ result :=  super openWithSpec ]
 ensure: [ SpecInterpreter bindings: old ].
 ^ result


 in TxAdapterBindings i initialize it same as morphic bindging, except from
 text model binding:
  #TextAdapter= #TxTextAdapter

 but it is never invoked nor used :(

 i understand the overall model, but it seems like not completely,
 (else the above trick would work).. what do i miss?

 --
 Best regards,
 Igor Stasenko.



You code works, it is just that the TextModel is not the first one that
calls the
spec interpreter. The first one is the WindowModel.
And after a spec is interpreted spec interpreter calls
self hardResetBindings
and that one reinitialize the binding to MorphicAdapterBindings.


nicolai


Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread stepharo

Hi nicolas

I agree with you :). My goal is not to drop strike fonts because I think 
that the code is working and it can be useful
for some people. I just want to make sure that StandardFonts (TextStyle 
and others...) does not mess up FreeType

and StrikeFonts. We got a lot of problems with this for our clients.

Stef


On 22/4/14 09:09, Nicolas Cellier wrote:


2014-04-22 6:30 GMT+02:00 Tudor Girba tu...@tudorgirba.com 
mailto:tu...@tudorgirba.com:


One question is why do still have the disable free type fonts option?
This was useful when free type was still in development, but I
think now it is no longer useful.
Or are there still use cases for it?

Doru



At the risk of repeating myself (that's maybe 10 times I say it here, 
but it's like shouting in the desert...) ,
freetype is pretty inefficient because it displays characters one by 
one (call a primitive foreach and every character).
So if you are on a not so fast device, strike fonts are still a good 
option because the primitive displays groups of characters in a batch.
So please, please, please, for once before breaking things that works 
and replacing them by a thing that works only partially,

do it the other way around:
- first make it fully work (that means add a new freetype primitive 
displaying batch of chars)

- then drop any historical bits you want

Of course, you are free to completely drop support for slow machines, 
but it must be consciously.



On Mon, Apr 21, 2014 at 7:32 PM, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:

Hi

when freetype is on do you think that it makes sense to have
strikeFont
proposed as default fonts? Like it is done right now, I get
bitmapVera even if I
want to see FreeType fonts.

Stef




-- 
www.tudorgirba.com http://www.tudorgirba.com


Every thing has its own flow






Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread stepharo


On 22/4/14 14:19, Tudor Girba wrote:

I do not see what this has to do with anything.

Right now we are offering the possibility to not be able to load 
FreeType fonts and this leads to buggy behavior when the user starts 
playing with that toggle.


In fact this is buggy even without that. The system reports strike and 
freetype fonts when we are in ft mode :(


I fail to see why we need the option in the first place. All I am 
saying is that we should remove the option from the settings browser 
and simply have the freetype fonts enable all the time. This means 
that you will still be able to load the bitmap fonts without problems 
just like before.


And it is our (as builders of Pharo) responsibilities to design. The 
user can say if he likes it or not and in our case can even try to 
contribute. But, this does not take the design responsibility from our 
shoulders.


Doru


On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner sergi.rey...@gmail.com 
mailto:sergi.rey...@gmail.com wrote:


2014-04-22 8:21 GMT+01:00 Tudor Girba tu...@tudorgirba.com
mailto:tu...@tudorgirba.com:

I am not arguing for dropping of bitmap fonts at all. I am
only arguing for removing the option of not having freetype.
People on slow devices will still be able to use the bitmap fonts.

Is that wrong?


Well, look at it this way: who should be able to have the final
word on what side of the speed/prettiness dichotomy Pharo should
be: the user or the system?

Cheers,
Sergi




--
www.tudorgirba.com http://www.tudorgirba.com

Every thing has its own flow




Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread Tudor Girba
Why is this buggy?

Right now, the meaning of the checkbox is to allow the user to have FT in
addition to bitmap fonts. That is why I say we should just drop the
checkbox altogether and we have solved a source of problems. We can rethink
the infrastructure for Pharo 4.

Doru


On Tue, Apr 22, 2014 at 9:30 PM, stepharo steph...@free.fr wrote:


 On 22/4/14 14:19, Tudor Girba wrote:

 I do not see what this has to do with anything.

  Right now we are offering the possibility to not be able to load
 FreeType fonts and this leads to buggy behavior when the user starts
 playing with that toggle.


 In fact this is buggy even without that. The system reports strike and
 freetype fonts when we are in ft mode :(


  I fail to see why we need the option in the first place. All I am saying
 is that we should remove the option from the settings browser and simply
 have the freetype fonts enable all the time. This means that you will still
 be able to load the bitmap fonts without problems just like before.

  And it is our (as builders of Pharo) responsibilities to design. The
 user can say if he likes it or not and in our case can even try to
 contribute. But, this does not take the design responsibility from our
 shoulders.

  Doru


 On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner sergi.rey...@gmail.comwrote:

  2014-04-22 8:21 GMT+01:00 Tudor Girba tu...@tudorgirba.com:

  I am not arguing for dropping of bitmap fonts at all. I am only arguing
 for removing the option of not having freetype. People on slow devices will
 still be able to use the bitmap fonts.

  Is that wrong?


  Well, look at it this way: who should be able to have the final word on
 what side of the speed/prettiness dichotomy Pharo should be: the user or
 the system?

  Cheers,
 Sergi




  --
 www.tudorgirba.com

  Every thing has its own flow





-- 
www.tudorgirba.com

Every thing has its own flow


Re: [Pharo-dev] About fonts (again)

2014-04-22 Thread Nicolas Cellier
2014-04-22 21:30 GMT+02:00 stepharo steph...@free.fr:


 On 22/4/14 14:19, Tudor Girba wrote:

 I do not see what this has to do with anything.

  Right now we are offering the possibility to not be able to load
 FreeType fonts and this leads to buggy behavior when the user starts
 playing with that toggle.


 In fact this is buggy even without that. The system reports strike and
 freetype fonts when we are in ft mode :(



Are you questionning about updateFontsAtImageStartup?
The reason for not wanting to update fonts at image startup was to avoid
loosing time at startup.
 http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009358.html
If this was a valuable setting at that time, what makes it not valuable now?

Or are you questionning about presence of FreeType fonts in FontChooser?
I have FT on but updateFTAtStartup off, and for seeing the FT fonts I have
to open the dialog, press update button, close the dialog, reopen, and only
then I can see the FreeType fonts.
Is that the bug you're after?


   I fail to see why we need the option in the first place. All I am
 saying is that we should remove the option from the settings browser and
 simply have the freetype fonts enable all the time. This means that you
 will still be able to load the bitmap fonts without problems just like
 before.

  And it is our (as builders of Pharo) responsibilities to design. The
 user can say if he likes it or not and in our case can even try to
 contribute. But, this does not take the design responsibility from our
 shoulders.

  Doru


 On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner sergi.rey...@gmail.comwrote:

  2014-04-22 8:21 GMT+01:00 Tudor Girba tu...@tudorgirba.com:

  I am not arguing for dropping of bitmap fonts at all. I am only arguing
 for removing the option of not having freetype. People on slow devices will
 still be able to use the bitmap fonts.

  Is that wrong?


  Well, look at it this way: who should be able to have the final word on
 what side of the speed/prettiness dichotomy Pharo should be: the user or
 the system?

  Cheers,
 Sergi




  --
 www.tudorgirba.com

  Every thing has its own flow





Re: [Pharo-dev] updated documentation on magritte?

2014-04-22 Thread p...@highoctane.be
On Tue, Apr 22, 2014 at 9:14 PM, Esteban Lorenzano esteba...@gmail.comwrote:


 On 22 Apr 2014, at 20:20, stepharo steph...@free.fr wrote:

  Not that I know.
  I started a chapter on the pharo for the entreprise (with the idea to
 base it on the seaside book) but I need help.
  If you start writing a draft I will do a pass.

 I was fearing that… but ok :)


I have collected quite a number of items regarding magritte. And I used 3.x
for one project of mine, which exposed a number of elements.

I'll try to make a package with all of it.

Phil


 
  Stef
 
  On 22/4/14 09:28, Esteban Lorenzano wrote:
  Hi,
 
  is there an updated documentation on magritte? where can I find it?
 
  cheers,
  Esteban
 
 
 
 





Re: [Pharo-dev] Pharo success story for Issys Tracking broken?

2014-04-22 Thread Torsten Bergmann
Yes - but the question remains where did this story come from. 
I would like to know more about it.

Thx
T.


 Gesendet: Dienstag, 22. April 2014 um 16:20 Uhr
 Von: Marcus Denker marcus.den...@inria.fr
 An: Pharo Development List pharo-dev@lists.pharo.org
 Betreff: Re: [Pharo-dev] Pharo success story for Issys Tracking broken?

 
 On 22 Apr 2014, at 13:53, Sean P. DeNigris s...@clipperadams.com wrote:
 
  Torsten Bergmann wrote
  Unfortunately none of the links work. Any infos on that?
  
  I did a little googling and checked the wayback machine; didn't come up with
  anything relevant…
  
 
 I have removed the article for now… 
 
   Marcus
 
 




Re: [Pharo-dev] Smalltalk Hub on Chrome

2014-04-22 Thread Sean P. DeNigris
It looks like this:

http://forum.world.st/file/n4755918/Screenshot_2014-04-22_22.png 



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788p4755918.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

2014-04-22 Thread Sean P. DeNigris
Stefan Marr-3 wrote
 Still, I will state it anyway: I don’t like the change.

I expected it to be unpopular ;)


Stefan Marr-3 wrote
 So, just for the sake of argument, are there other ways?

I don't know. I'm open...

As far as making #= mean something different the first time, I think this
gets us further down the difficult-to-understand rabbit hole. Also, #= is
not always sent; it's one of several options, like #beFalse. I guess maybe
you could say as soon as any expectation is set up, revert to a traditional
#=. But philosophically, hijacking #= disrupts the uniformity of the system
and adds to the user's cognitive load. Hijacking it only some of the time
makes it even less predictable.

And, what's the specific argument for keeping the behavior of #=? Am I
missing some value that makes it worth all of the above? I think it's
important to separate the logic from the inertia inevitably accompanying
this kind of change.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Destroying-Bug-tp4755787p4755919.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

2014-04-22 Thread Eliot Miranda
On Tue, Apr 22, 2014 at 7:26 PM, Sean P. DeNigris s...@clipperadams.comwrote:

 Stefan Marr-3 wrote
  Still, I will state it anyway: I don’t like the change.

 I expected it to be unpopular ;)


 Stefan Marr-3 wrote
  So, just for the sake of argument, are there other ways?

 I don't know. I'm open...

 As far as making #= mean something different the first time, I think this
 gets us further down the difficult-to-understand rabbit hole. Also, #= is
 not always sent; it's one of several options, like #beFalse. I guess maybe
 you could say as soon as any expectation is set up, revert to a
 traditional
 #=. But philosophically, hijacking #= disrupts the uniformity of the system
 and adds to the user's cognitive load. Hijacking it only some of the time
 makes it even less predictable.


+1.

And, what's the specific argument for keeping the behavior of #=? Am I
 missing some value that makes it worth all of the above? I think it's
 important to separate the logic from the inertia inevitably accompanying
 this kind of change.



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Destroying-Bug-tp4755787p4755919.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.




-- 
best,
Eliot