[Pharo-project] [ANN] Pharo 1.0 Beta
Hi all, We are excited to announce the first Pharo 1.0 beta release. A new Pharo image (and also Pharo-web image) can be downloaded from the website: http://pharo.cmsbox.ch/pharo-download The corresponding version number of Pharo-core is #10401. I'd like to thank all the people that have contributed to Pharo so far! Have fun, Adrian BTW, I also wrote about Pharo and the beta release on http://www.adrian-lienhard.ch/blog ___________________ http://www.adrian-lienhard.ch/
Congratulations! Doru On 31 Jul 2009, at 10:42, Adrian Lienhard wrote:
Hi all,
We are excited to announce the first Pharo 1.0 beta release.
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
http://pharo.cmsbox.ch/pharo-download
The corresponding version number of Pharo-core is #10401.
I'd like to thank all the people that have contributed to Pharo so far!
Have fun, Adrian
BTW, I also wrote about Pharo and the beta release on http://www.adrian-lienhard.ch/blog
___________________ http://www.adrian-lienhard.ch/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."
On Fri, Jul 31, 2009 at 3:42 PM, Adrian Lienhard<adi@netstyle.ch> wrote:
Hi all,
We are excited to announce the first Pharo 1.0 beta release.
Congratulations to the Pharo team !
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
This is not ? http://www.pharo-project.org/pharo-download -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
On Jul 31, 2009, at 11:09 , Serge Stinckwich wrote:
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
This is not ? http://www.pharo-project.org/pharo-download
Yes, of course. The other one is an internal URL, but it points to the same content. Sorry for the confusion. Adrian
I just spotted that the hint text of the "Quit" menu item says: "Quit out of Squeak" Similarly for "Save and quit". Perhaps this could be changed? Cheers, Doru On 31 Jul 2009, at 11:25, Adrian Lienhard wrote:
On Jul 31, 2009, at 11:09 , Serge Stinckwich wrote:
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
This is not ? http://www.pharo-project.org/pharo-download
Yes, of course. The other one is an internal URL, but it points to the same content. Sorry for the confusion.
Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Be rather willing to give than demanding to get."
On Fri, Jul 31, 2009 at 11:44 AM, Tudor Girba<girba@iam.unibe.ch> wrote:
I just spotted that the hint text of the "Quit" menu item says:
"Quit out of Squeak"
Similarly for "Save and quit". Perhaps this could be changed?
Fixed in http://code.google.com/p/pharo/issues/detail?id=1021. Thank you for the report. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
On 31.07.2009, at 05:44, Tudor Girba wrote:
I just spotted that the hint text of the "Quit" menu item says:
"Quit out of Squeak"
Similarly for "Save and quit". Perhaps this could be changed?
Yes, the Mac menus need to be improved. e.g. there should be just one Pharo menu instead of "Squeak VM" and "Files"... I will have a look at that soon. Marcus -- Marcus Denker -- marcus@2denker.de http://www.2denker.de 2denker UG (haftungsbeschränkt) Sitz Köln Amtsgericht - Registergericht - Köln, HRB 65065 Geschäftsführer: Christian Denker und Dr. Marcus Denker
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha? Stef
Hi all,
We are excited to announce the first Pharo 1.0 beta release.
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
http://pharo.cmsbox.ch/pharo-download
The corresponding version number of Pharo-core is #10401.
I'd like to thank all the people that have contributed to Pharo so far!
Have fun, Adrian
BTW, I also wrote about Pharo and the beta release on http://www.adrian-lienhard.ch/blog
___________________ http://www.adrian-lienhard.ch/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
On 01.08.2009, at 07:06, Serge Stinckwich wrote:
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions.
Yes, I think this is the way to go... we should force everyone to use the beta version for a while. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
On 01.08.2009, at 07:06, Serge Stinckwich wrote:
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions.
Yes, I think this is the way to go... we should force everyone to use the beta version for a while.
Yes. We have 50 open issues for 1.0 and when more people start using Pharo, they will find more bugs. So for now we should focus on bringing that number down to 0. Adrian
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ok with me. Stef On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
On 01.08.2009, at 07:06, Serge Stinckwich wrote:
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions.
Yes, I think this is the way to go... we should force everyone to use the beta version for a while.
Yes. We have 50 open issues for 1.0 and when more people start using Pharo, they will find more bugs. So for now we should focus on bringing that number down to 0.
Adrian
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hmm, so bugs are ok? Does this also include primitive (or plugib) failures which are handled correctly, but cause performance problems? In particular, I'm thinking of primitive 103 in core (used in strikefont rendering), and plugin BitBlt using rule 41 (used in FTFont-rendering), whom (wild guess) both seem to have problem with the String -> ByteString/WideString refactoring... (IE: they fail in Pharo with a ByteString parameter instead of String, and use the strictly smalltalk fallback code resulting in... far worse performance) I tried installing VMMaker to investigate the problems further, but I guess the steps needed to set up an interpreter to properly test exactly what goes wrong in these cases were too advanced for me to figure out in 30 mins.. :( BTW, the Cuis subpixel-rendering looks beautiful (both performance and code-wise) compared to what is done in the FreeType code. Anyone have time to understand/integrate this approach before 1.0 release? Misc ideas: - How about inserting some sort of logging where primitives are called with failure, but Smalltalk code fallback is used for a seemingly successful result. then fixing the code/VM to handle those cases? Font rendering is the prime cultrip, but I'm sure there are other places as well.... Secondary: - How about another instance cache in Color, for transformed colours? Some of these transformed colours are used MANY times during each rendering step, (look at the senders of Color>>lighter f.ex.), it seems silly to create new Color object that have to be GC'd in many of these instances. In Pharo the overhead isn't very noticeable (due to the primitive failures mentioned above sucking up most of the processor time), but in a lean system like Cuis, they did appear on TimeProfiles... I'm not sure how much you can trust the leaf nodes of TimeProfiles though, at least in Cuis/(which I did most of my investigation in), they seemed to be spread at random between items in a block.... (IE: from one to another, it could shift from 90% in one method call to 90% in another method call in the same block). If you read this entire message, you have my condolances, and written permission to ask for clarifications :) Cheers, Henry , On 04.08.2009 16:44, Stéphane Ducasse wrote:
ok with me.
Stef
On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
On 01.08.2009, at 07:06, Serge Stinckwich wrote:
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions.
Yes, I think this is the way to go... we should force everyone to use the beta version for a while.
Yes. We have 50 open issues for 1.0 and when more people start using Pharo, they will find more bugs. So for now we should focus on bringing that number down to 0.
Adrian
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 04.08.2009, at 18:49, Henrik Sperre Johansen wrote:
Hmm, so bugs are ok?
Why? Nobody said that we will not mark more issues as to be fixed for 1.0... what was said is that we will not have a second stream and start to add fixes that are decided to not be included in 1.0 there. Nothing else. If you want other reports to be tagges 1.0, add a note in the bugreport. If you find new bugs, add a new report and tell the world that you think that it needs to be fixed for 1.0. Marcus
Does this also include primitive (or plugib) failures which are handled correctly, but cause performance problems?
In particular, I'm thinking of primitive 103 in core (used in strikefont rendering), and plugin BitBlt using rule 41 (used in FTFont- rendering), whom (wild guess) both seem to have problem with the String -> ByteString/WideString refactoring... (IE: they fail in Pharo with a ByteString parameter instead of String, and use the strictly smalltalk fallback code resulting in... far worse performance)
I tried installing VMMaker to investigate the problems further, but I guess the steps needed to set up an interpreter to properly test exactly what goes wrong in these cases were too advanced for me to figure out in 30 mins.. :(
BTW, the Cuis subpixel-rendering looks beautiful (both performance and code-wise) compared to what is done in the FreeType code. Anyone have time to understand/integrate this approach before 1.0 release?
Misc ideas: - How about inserting some sort of logging where primitives are called with failure, but Smalltalk code fallback is used for a seemingly successful result. then fixing the code/VM to handle those cases? Font rendering is the prime cultrip, but I'm sure there are other places as well....
Secondary: - How about another instance cache in Color, for transformed colours? Some of these transformed colours are used MANY times during each rendering step, (look at the senders of Color>>lighter f.ex.), it seems silly to create new Color object that have to be GC'd in many of these instances. In Pharo the overhead isn't very noticeable (due to the primitive failures mentioned above sucking up most of the processor time), but in a lean system like Cuis, they did appear on TimeProfiles...
I'm not sure how much you can trust the leaf nodes of TimeProfiles though, at least in Cuis/(which I did most of my investigation in), they seemed to be spread at random between items in a block.... (IE: from one to another, it could shift from 90% in one method call to 90% in another method call in the same block).
If you read this entire message, you have my condolances, and written permission to ask for clarifications :)
Cheers, Henry
, On 04.08.2009 16:44, Stéphane Ducasse wrote:
ok with me.
Stef
On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
On 01.08.2009, at 07:06, Serge Stinckwich wrote:
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions.
Yes, I think this is the way to go... we should force everyone to use the beta version for a while.
Yes. We have 50 open issues for 1.0 and when more people start using Pharo, they will find more bugs. So for now we should focus on bringing that number down to 0.
Adrian
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 04.08.2009, at 18:58, Marcus Denker wrote:
On 04.08.2009, at 18:49, Henrik Sperre Johansen wrote:
Hmm, so bugs are ok?
Why? Nobody said that we will not mark more issues as to be fixed for 1.0... what was said is that we will not have a second stream and start to add fixes that are decided to not be included in 1.0 there. Nothing else.
If you want other reports to be tagges 1.0, add a note in the bugreport. If you find new bugs, add a new report and tell the world that you think that it needs to be fixed for 1.0.
another note: It should be clear that a release always is just a snapshot. There will not be all problems solved. The idea is to just denote one version as "we used this for a while and it seems to work ok for most people". Nothing else. If somebody want to wait for perfection, Pharo is not the place to be. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi henrik what I suggest is: cut your messages into smaller ones so that we can get multiple and clear thread. Then enter bug items when needed. Stef On Aug 5, 2009, at 12:49 AM, Henrik Sperre Johansen wrote:
Hmm, so bugs are ok?
Does this also include primitive (or plugib) failures which are handled correctly, but cause performance problems?
In particular, I'm thinking of primitive 103 in core (used in strikefont rendering), and plugin BitBlt using rule 41 (used in FTFont- rendering), whom (wild guess) both seem to have problem with the String -> ByteString/WideString refactoring... (IE: they fail in Pharo with a ByteString parameter instead of String, and use the strictly smalltalk fallback code resulting in... far worse performance)
I tried installing VMMaker to investigate the problems further, but I guess the steps needed to set up an interpreter to properly test exactly what goes wrong in these cases were too advanced for me to figure out in 30 mins.. :(
BTW, the Cuis subpixel-rendering looks beautiful (both performance and code-wise) compared to what is done in the FreeType code. Anyone have time to understand/integrate this approach before 1.0 release?
Misc ideas: - How about inserting some sort of logging where primitives are called with failure, but Smalltalk code fallback is used for a seemingly successful result. then fixing the code/VM to handle those cases? Font rendering is the prime cultrip, but I'm sure there are other places as well....
Secondary: - How about another instance cache in Color, for transformed colours? Some of these transformed colours are used MANY times during each rendering step, (look at the senders of Color>>lighter f.ex.), it seems silly to create new Color object that have to be GC'd in many of these instances. In Pharo the overhead isn't very noticeable (due to the primitive failures mentioned above sucking up most of the processor time), but in a lean system like Cuis, they did appear on TimeProfiles...
I'm not sure how much you can trust the leaf nodes of TimeProfiles though, at least in Cuis/(which I did most of my investigation in), they seemed to be spread at random between items in a block.... (IE: from one to another, it could shift from 90% in one method call to 90% in another method call in the same block).
If you read this entire message, you have my condolances, and written permission to ask for clarifications :)
Cheers, Henry
, On 04.08.2009 16:44, Stéphane Ducasse wrote:
ok with me.
Stef
On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
On 01.08.2009, at 07:06, Serge Stinckwich wrote:
On Sat, Aug 1, 2009 at 2:41 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
So what is the process now? Do we focus on 1.0? Can we integrate other issues? Do we have a separate stream for 1.1 alpha?
Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions.
Yes, I think this is the way to go... we should force everyone to use the beta version for a while.
Yes. We have 50 open issues for 1.0 and when more people start using Pharo, they will find more bugs. So for now we should focus on bringing that number down to 0.
Adrian
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Will do! Submitted Issue 1041 as a simple case where an (unneccessary) primitive failure happens. If a similar slowdown is experienced in f.ex. the fallback bitblt code used in font rendering, it might be worth investigating what exactly causes it to fail. Fallback code isn't always a good thing when everything still works as expected, but cause performance hits that add up over time, and are hard to track down :) Cheers, Henry On Aug 5, 2009, at 9:42 27AM, Stéphane Ducasse wrote:
Hi henrik
what I suggest is: cut your messages into smaller ones so that we can get multiple and clear thread. Then enter bug items when needed.
Stef
excellent! for the color enh please generate a thread like that we can do something after. Stef On Aug 5, 2009, at 2:07 PM, Henrik Johansen wrote:
Will do! Submitted Issue 1041 as a simple case where an (unneccessary) primitive failure happens. If a similar slowdown is experienced in f.ex. the fallback bitblt code used in font rendering, it might be worth investigating what exactly causes it to fail.
Fallback code isn't always a good thing when everything still works as expected, but cause performance hits that add up over time, and are hard to track down :)
Cheers, Henry
On Aug 5, 2009, at 9:42 27AM, Stéphane Ducasse wrote:
Hi henrik
what I suggest is: cut your messages into smaller ones so that we can get multiple and clear thread. Then enter bug items when needed.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
1000 timesRepeat:['yay!']. 1000 timesRepeat:['thanks!']. 1000 timesRepeat:['Pharo rulez']. sebastian
-----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de Adrian Lienhard Enviado el: Friday, July 31, 2009 05:42 Para: Pharo Development Asunto: [Pharo-project] [ANN] Pharo 1.0 Beta
Hi all,
We are excited to announce the first Pharo 1.0 beta release.
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
http://pharo.cmsbox.ch/pharo-download
The corresponding version number of Pharo-core is #10401.
I'd like to thank all the people that have contributed to Pharo so far!
Have fun, Adrian
BTW, I also wrote about Pharo and the beta release on http://www.adrian-lienhard.ch/blog
___________________ http://www.adrian-lienhard.ch/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2 things bugging me on Mac with the beta "dev" image: (Not sure if you could call them bugs, since they seem to be artifacts caused in some way by initialization needed but not done by the build script) - System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow. - Close/minimize buttons on windows in the background do not show unless you hover over them. This can be fixed by changing to another window theme, then back to Watery2. Cheers and congrats! Henry On Jul 31, 2009, at 10:42 05AM, Adrian Lienhard wrote:
Hi all,
We are excited to announce the first Pharo 1.0 beta release.
A new Pharo image (and also Pharo-web image) can be downloaded from the website:
http://pharo.cmsbox.ch/pharo-download
The corresponding version number of Pharo-core is #10401.
I'd like to thank all the people that have contributed to Pharo so far!
Have fun, Adrian
BTW, I also wrote about Pharo and the beta release on http://www.adrian-lienhard.ch/blog
___________________ http://www.adrian-lienhard.ch/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Aug 3, 2009 at 6:05 PM, Henrik Johansen<henrik.s.johansen@veloxit.no> wrote:
2 things bugging me on Mac with the beta "dev" image: (Not sure if you could call them bugs, since they seem to be artifacts caused in some way by initialization needed but not done by the build script)
- System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow.
- Close/minimize buttons on windows in the background do not show unless you hover over them. This can be fixed by changing to another window theme, then back to Watery2.
Yes +1 for this one. Maybe buttons can be drawn in gray when the focus is not on the window, as done in mac os X UI. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
On Aug 3, 2009, at 1:15 04PM, Serge Stinckwich wrote:
On Mon, Aug 3, 2009 at 6:05 PM, Henrik Johansen<henrik.s.johansen@veloxit.no> wrote:
2 things bugging me on Mac with the beta "dev" image: (Not sure if you could call them bugs, since they seem to be artifacts caused in some way by initialization needed but not done by the build script)
- System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow.
- Close/minimize buttons on windows in the background do not show unless you hover over them. This can be fixed by changing to another window theme, then back to Watery2.
Yes +1 for this one. Maybe buttons can be drawn in gray when the focus is not on the window, as done in mac os X UI.
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
That´s what they do, once you change theme and back again :) Cheers, Henry
On Mon, Aug 3, 2009 at 10:15 AM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Aug 3, 2009 at 6:05 PM, Henrik Johansen<henrik.s.johansen@veloxit.no> wrote:
2 things bugging me on Mac with the beta "dev" image: (Not sure if you could call them bugs, since they seem to be artifacts caused in some way by initialization needed but not done by the build script)
- System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow.
I don't know if I understood corrrectly but did you try turning on "fastDragWindowForMorphic" ?
- Close/minimize buttons on windows in the background do not show unless you hover over them. This can be fixed by changing to another window theme, then back to Watery2.
Yes +1 for this one. Maybe buttons can be drawn in gray when the focus is not on the window, as done in mac os X UI.
+1 also for this one.
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 3, 2009, at 3:26 03PM, Mariano Martinez Peck wrote:
On Mon, Aug 3, 2009 at 10:15 AM, Serge Stinckwich <serge.stinckwich@gmail.com
wrote: On Mon, Aug 3, 2009 at 6:05 PM, Henrik Johansen<henrik.s.johansen@veloxit.no> wrote: 2 things bugging me on Mac with the beta "dev" image: (Not sure if you could call them bugs, since they seem to be artifacts caused in some way by initialization needed but not done by the build script)
- System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow.
I don't know if I understood corrrectly but did you try turning on "fastDragWindowForMorphic" ?
No. This is with an image just opened after downloading, nothing changed from default settings. After resizing so the "correct" dropshadow behaviour is initialized, dragging is quite snappy even without fastDrag. (resizing is still slow, of course) I attached two images to 1026, so you can see the visual difference if you want. Cheers, Henry
Hi Henry, On Mon, Aug 3, 2009 at 1:05 PM, Henrik Johansen<henrik.s.johansen@veloxit.no> wrote:
- System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow.
- Close/minimize buttons on windows in the background do not show unless you hover over them. This can be fixed by changing to another window theme, then back to Watery2.
please report these two bugs on the issue tracker in two different reports. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
participants (10)
-
Adrian Lienhard -
Damien Cassou -
Henrik Johansen -
Henrik Sperre Johansen
-
Marcus Denker -
Mariano Martinez Peck -
Sebastian Sastre -
Serge Stinckwich -
Stéphane Ducasse -
Tudor Girba