Discussion:
[Pharo-dev] New Year Wishlist (2018) ?
Esteban Lorenzano
2017-12-23 16:58:22 UTC
Permalink
Hi everybody,

This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc…. whatever you want.

Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)

So, let’s those wishes come!

cheers,
Esteban
Cyril Ferlicot D.
2017-12-23 17:57:13 UTC
Permalink
Post by Esteban Lorenzano
Hi everybody,
Hi :)
Post by Esteban Lorenzano
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
I'll list the things I wanted the most those last months :)

- To be able to load a private git project from a private server via
Metacello API
- To be able to depend on a git project from a private server in
BaselineOf/ConfigurationOf
- 64bits vm more recent that does not crash 1/4 of the time (It would
help to deploy apps for some customers with older linux distributions)
- 64bits Windows vm (But as far as I know, there is progress on this
side already)
- Continue to push Iceberg (I am not really specific because I want a
lot on that part. For more details, I open issues on Iceberg repository
often :) )

All those points are in the optic to make business with Pharo easier.
Post by Esteban Lorenzano
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
Of course :)
Post by Esteban Lorenzano
So, let’s those wishes come!
Also, I would like to thanks everyone because I really like my Pharo
journey and it would not be possible without you! :)
Post by Esteban Lorenzano
cheers,
Esteban
--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Sean P. DeNigris
2017-12-23 21:54:41 UTC
Permalink
- To be able to depend on a git project from a private server/
*
repo
*
in
BaselineOf/ConfigurationOf
*
and automatically clone using SSH keys if needed
*
(Additions to above in bold)
STABILITY
Of course!

I've been dreaming of most of the rest of my wishlist since 1.1, and it
seems we've been creeping closer and closer:
- Clean, stable low-level UI framework preserving the liveness and
directness of Morphic, which also is infinitely zoomable and supports
multiple (potentially simultaneously-running) worlds
- 100% customizable (per instance) keybindings
- Clean, customizable text editor with intuitive text model (sad to see Tx
disappear, but we seem to have a replacement brewing)
- Multi OS window support (not sure how close we are here)
- Versionner (or its replacement) support for Baselines - hand editing is a
draaaag

Overall, I'm very thankful for all the progress we've made so far. Many of
my wishlist items have been crossed off. Some bigger ones were:
- Intuitive file library (FS)
- Easy (low-barrier) contribution to other people's projects (via git/GH
support)
- Image management (Launcher)
- Image auto-customization (startup scripts)
- Single FFI library with must-have features from different existing (e.g.
async callbacks) (almost there?)
- Lots of integration with standard formats (NeoCSV/JSON, Pillar for MD)
- Massive CI, including issue tracker integration
- Cherry pick commits (Iceberg and Komitter before)
- Real package model, with meta-data (RPackage and manifests)
- In-editor critics with auto-transformations

I can't wait to see what 2018 brings!



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cyril Ferlicot D.
2017-12-27 15:41:56 UTC
Permalink
Post by Cyril Ferlicot D.
Post by Esteban Lorenzano
Hi everybody,
Hi :)
Post by Esteban Lorenzano
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
I'll list the things I wanted the most those last months :)
- To be able to load a private git project from a private server via
Metacello API
- To be able to depend on a git project from a private server in
BaselineOf/ConfigurationOf
- 64bits vm more recent that does not crash 1/4 of the time (It would
help to deploy apps for some customers with older linux distributions)
- 64bits Windows vm (But as far as I know, there is progress on this
side already)
- Continue to push Iceberg (I am not really specific because I want a
lot on that part. For more details, I open issues on Iceberg repository
often :) )
All those points are in the optic to make business with Pharo easier.
I also forgot: a real headless :)
Post by Cyril Ferlicot D.
Post by Esteban Lorenzano
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
Of course :)
Post by Esteban Lorenzano
So, let’s those wishes come!
Also, I would like to thanks everyone because I really like my Pharo
journey and it would not be possible without you! :)
Post by Esteban Lorenzano
cheers,
Esteban
--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Pierce Ng
2017-12-29 01:47:45 UTC
Permalink
Post by Cyril Ferlicot D.
I also forgot: a real headless :)
And real "embeddability". :-) I'll write GUIs with Pascal/Lazarus if I must.
Being able to implement domain logic stuff in Pharo embedded into the
application will super charge productivity.

Pierce
philippe.back@highoctane.be
2017-12-29 10:32:52 UTC
Permalink
Post by Cyril Ferlicot D.
I also forgot: a real headless :)
And real "embeddability". :-) I'll write GUIs with Pascal/Lazarus if I must.


That would actually suit me very well too.

Being able to implement domain logic stuff in Pharo embedded into the
application will super charge productivity.


+1 million

Phil


Pierce
Stéphane Ducasse
2017-12-23 19:45:22 UTC
Permalink
Sounds like a good wish list!
Dear Santa,
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
- STABILITY
Thanks a lot!
Your Robert
--
Ing. Robert Pergl, Ph.D.
Assistant Professor at Department of Software Engineering
Head of Centre for Conceptual Modelling and Implementation
ELIXIR CZ representative in the Interoperability Platform
Czech Technical University in Prague, Faculty of Information Technology
Thákurova 9, 160 00 Praha 6, Czech Republic
room: A-935
http://ccmi.fit.cvut.cz <http://ccmi.fit.cvut.cz/>
http://www.fit.cvut.cz/en <http://www.fit.cvut.cz/en>
tel.: +420 777 042 249
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
Alexandre Bergel
2017-12-24 01:59:40 UTC
Permalink
My four wishes, in no particular order:
- Better code completion
- Git in Pharo as easy as using Git for other languages
- Bloc on Steroid
- Being able to interrupt any process and endless loop using Cmd-.

Merry Christmas to all of you!
Alexandre
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc…. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
Torsten Bergmann
2017-12-24 13:34:19 UTC
Permalink
Hi Esteban,

Many things come to mind:

vm side
=======
- working SSL for all platforms supporting newest TLS
- Pharo 64 bit VM for Windows
- better and more VM plugins (like the camera plugin which would allow us more collaboration)
- threaded vm for non-blocking usage
- the VM in a DLL

image
- cleaning up
- Calypso inclusion
- Class annotations in the default image
- Versionner for editing baselines (instead of manually editing dependencies)
- unification of all the quality rules
- support for other content types in browser (like highlighted XML, JSON, Js, ...)
and managing non-smalltalk project code in git too at the level of projects
- better completion
- Bloc inclusion of blocs
- better widgets and UI
- a better catalog ("Index")
- a better file browser
- filing in/filing out Tonel files also in browser, change sorter, file list (similar to st files)
- support for I18N (with tools, maybe binding to lib gettext)

general
- even more tech talks
- more collaboration tools

Also:
- making a stable but updateable launcher the default install which is working on all platforms
so one can use it for Pharo installation and sorting out version or platform specific install issues.

If the list is too short then tell me ;)

Bye
T.
Gesendet: Samstag, 23. Dezember 2017 um 17:58 Uhr
Betreff: [Pharo-dev] New Year Wishlist (2018) ?
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc…. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
Alistair Grant
2017-12-24 14:48:17 UTC
Permalink
Hi Esteban,

- https://github.com/pharo-project/pharo-vm/pull/142

Thanks!
Alistair
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc…. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
Denis Kudriashov
2017-12-24 18:13:46 UTC
Permalink
Hi.

Not blocking FFI, please
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you
want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
Of course, this list will not be a roadmap and it does not means we will
implement all of it (as always, time drives our possibilities), but is a
good moment for us a a community to check where we are and where we wan to
go next :)
So, let’s those wishes come!
cheers,
Esteban
Dimitris Chloupis
2017-12-24 19:57:12 UTC
Permalink
For me 100% bootstrap and anything that helps me minimize the image or
completely get rid of it.

Second place is a GUI designer.

Third place, world peace.

Santa hates me :D
Post by Denis Kudriashov
Hi.
Not blocking FFI, please
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would
you want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
Of course, this list will not be a roadmap and it does not means we will
implement all of it (as always, time drives our possibilities), but is a
good moment for us a a community to check where we are and where we wan to
go next :)
So, let’s those wishes come!
cheers,
Esteban
Hilaire
2017-12-25 11:33:59 UTC
Permalink
Oh, you asked for that Esteban :)

1. stability

2. Tonel is a nice way to export file (its granularity is just right,
bravo Esteban!) and commit to arbitrary repository, experimenting it
with DrGeo, and it is nice to commit code[1] along other data files of
the project (graphics, doc, translation, etc.). Got some an when non
ascii characters were present in the source code, people reported it
there. Likely to be fixed :)

3. vectorial interface, oh already on its way

4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at
some time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some ;-)

5. fulfill the promise of tiny image, aka bootstrap and 4.

All these wishes are under construction, so likely to happen \o/


I have personal three wishes (beside good health of course), sharing it
in case others are interested to hack on it too:

A. get DrGeo working on P7, particularly on the bootstrap process.

B. Build an environment in Pharo to develop simple games, targeted for
kids. There are some teenagers in my school likely to get interested on
such courses. If it could result in standalone games build thanks to
wish 4., so good.

C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods
(can't get the right tooling to do geometry for example), handwriting is
not nice, hacking on it is super complicated (C++ code), not to mention
the building process. A Pharo based one will be fantastic and much easy
to hack.


Have a nice Christmas!


[1]
http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/
[2] http://openboard.ch
Post by Esteban Lorenzano
So, let’s those wishes come!
--
Dr. Geo
http://drgeo.eu
Torsten Bergmann
2017-12-25 13:17:45 UTC
Permalink
A GUI builder is always a nice thing ... and there already was an attempt
for Pharo:

http://www.squeaksource.com/UIBuilder/

Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. That version
only works in Pharo 1.1. Is opened for any developer.".

Dont know why it failed ... maybe because the UI (especially with Morphic legacy)
is still too shaky are in Pharo.

But I guess the order will be/needs to be:

- good and stable graphics framework (maybe solved with Bloc)
- good and stable standardized widget set (maybe solved with Brick)
- then place a UI builder on top of it

Bye
T.
Gesendet: Montag, 25. Dezember 2017 um 12:33 Uhr
Betreff: Re: [Pharo-dev] New Year Wishlist (2018) ?
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right,
bravo Esteban!) and commit to arbitrary repository, experimenting it
with DrGeo, and it is nice to commit code[1] along other data files of
the project (graphics, doc, translation, etc.). Got some an when non
ascii characters were present in the source code, people reported it
there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at
some time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
All these wishes are under construction, so likely to happen \o/
I have personal three wishes (beside good health of course), sharing it
A. get DrGeo working on P7, particularly on the bootstrap process.
B. Build an environment in Pharo to develop simple games, targeted for
kids. There are some teenagers in my school likely to get interested on
such courses. If it could result in standalone games build thanks to
wish 4., so good.
C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods
(can't get the right tooling to do geometry for example), handwriting is
not nice, hacking on it is super complicated (C++ code), not to mention
the building process. A Pharo based one will be fantastic and much easy
to hack.
Have a nice Christmas!
[1]
http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/
[2] http://openboard.ch
Post by Esteban Lorenzano
So, let’s those wishes come!
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-25 14:58:05 UTC
Permalink
Post by Torsten Bergmann
A GUI builder is always a nice thing ... and there already was an attempt
http://www.squeaksource.com/UIBuilder/
Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. That version
only works in Pharo 1.1. Is opened for any developer.".
Dont know why it failed ... maybe because the UI (especially with Morphic legacy)
is still too shaky are in Pharo.
The developer stopped when he saw that he could not build a excel like grid.
I tried to rescue its effort but it was too large to recover.
Post by Torsten Bergmann
- good and stable graphics framework (maybe solved with Bloc)
- good and stable standardized widget set (maybe solved with Brick)
- then place a UI builder on top of it
Bye
T.
Gesendet: Montag, 25. Dezember 2017 um 12:33 Uhr
Betreff: Re: [Pharo-dev] New Year Wishlist (2018) ?
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right,
bravo Esteban!) and commit to arbitrary repository, experimenting it
with DrGeo, and it is nice to commit code[1] along other data files of
the project (graphics, doc, translation, etc.). Got some an when non
ascii characters were present in the source code, people reported it
there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at
some time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
All these wishes are under construction, so likely to happen \o/
I have personal three wishes (beside good health of course), sharing it
A. get DrGeo working on P7, particularly on the bootstrap process.
B. Build an environment in Pharo to develop simple games, targeted for
kids. There are some teenagers in my school likely to get interested on
such courses. If it could result in standalone games build thanks to
wish 4., so good.
C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods
(can't get the right tooling to do geometry for example), handwriting is
not nice, hacking on it is super complicated (C++ code), not to mention
the building process. A Pharo based one will be fantastic and much easy
to hack.
Have a nice Christmas!
[1]
http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/
[2] http://openboard.ch
Post by Esteban Lorenzano
So, let’s those wishes come!
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-25 14:59:28 UTC
Permalink
About the application builder we will continue to work on the effort
and lamrc is interested to show that we can
build real applications with Pharo. So I really hope that something
will happen this year.

Stef

On Mon, Dec 25, 2017 at 3:58 PM, Stephane Ducasse
Post by Stephane Ducasse
Post by Torsten Bergmann
A GUI builder is always a nice thing ... and there already was an attempt
http://www.squeaksource.com/UIBuilder/
Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. That version
only works in Pharo 1.1. Is opened for any developer.".
Dont know why it failed ... maybe because the UI (especially with Morphic legacy)
is still too shaky are in Pharo.
The developer stopped when he saw that he could not build a excel like grid.
I tried to rescue its effort but it was too large to recover.
Post by Torsten Bergmann
- good and stable graphics framework (maybe solved with Bloc)
- good and stable standardized widget set (maybe solved with Brick)
- then place a UI builder on top of it
Bye
T.
Gesendet: Montag, 25. Dezember 2017 um 12:33 Uhr
Betreff: Re: [Pharo-dev] New Year Wishlist (2018) ?
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right,
bravo Esteban!) and commit to arbitrary repository, experimenting it
with DrGeo, and it is nice to commit code[1] along other data files of
the project (graphics, doc, translation, etc.). Got some an when non
ascii characters were present in the source code, people reported it
there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at
some time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
All these wishes are under construction, so likely to happen \o/
I have personal three wishes (beside good health of course), sharing it
A. get DrGeo working on P7, particularly on the bootstrap process.
B. Build an environment in Pharo to develop simple games, targeted for
kids. There are some teenagers in my school likely to get interested on
such courses. If it could result in standalone games build thanks to
wish 4., so good.
C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods
(can't get the right tooling to do geometry for example), handwriting is
not nice, hacking on it is super complicated (C++ code), not to mention
the building process. A Pharo based one will be fantastic and much easy
to hack.
Have a nice Christmas!
[1]
http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/
[2] http://openboard.ch
Post by Esteban Lorenzano
So, let’s those wishes come!
--
Dr. Geo
http://drgeo.eu
Ben Coman
2017-12-25 22:37:16 UTC
Permalink
Post by Torsten Bergmann
Post by Torsten Bergmann
A GUI builder is always a nice thing ... and there already was an attempt
http://www.squeaksource.com/UIBuilder/
Now marked as "Failed attempt of develop a UI builder for
Pharo-Smalltalk. That version
Post by Torsten Bergmann
only works in Pharo 1.1. Is opened for any developer.".
Dont know why it failed ... maybe because the UI (especially with
Morphic legacy)
Post by Torsten Bergmann
is still too shaky are in Pharo.
The developer stopped when he saw that he could not build a excel like grid.
Oh, then let me add an Excel-like grid as my Christmas wish
(or does FastTable already provide much of this?)

cheers -ben
Hilaire
2017-12-25 17:23:07 UTC
Permalink
In case of, at wish 4. I did not write a GUI builder but really an
application builder: a tool to let you build up the image and the needed
VMs, and pack it appropriately for the end user. As it is manually done
for Dr.Geo.
Post by Torsten Bergmann
A GUI builder is always a nice thing ... and there already was an attempt
--
Dr. Geo
http://drgeo.eu
Dimitris Chloupis
2017-12-25 19:29:55 UTC
Permalink
Post by Torsten Bergmann
A GUI builder is always a nice thing ... and there already was an attempt
http://www.squeaksource.com/UIBuilder/
Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. That version
only works in Pharo 1.1. Is opened for any developer.".
Dont know why it failed ... maybe because the UI (especially with Morphic legacy)
is still too shaky are in Pharo.
- good and stable graphics framework (maybe solved with Bloc)
- good and stable standardized widget set (maybe solved with Brick)
- then place a UI builder on top of it
Bye
Yeap that's the ideology about GUI designers , which is why so few IDE's
have them. It's like the man waiting for the perfect woman to marry, ending
up all alone and miserable.

As a designer myself I cannot follow easily this ideology. Actually I
cannot follow it at all.

I see it the exact opposite way, if you don't have a good GUI designer ,
your ability to provide a stable and powerful GUI API will be limited
because less people will use it.

The most stable and powerful GUI api I ever used was VCL , the standard
library of Delphi and surprise, surprise it has a GUI designer. The most
powerful I used so far.

Open source wise QT dominates , surprise , surprise it has a very powerful
GUI designer.

On Windows you have VS studio GUI designer on MacOS and iOS the XCode GUI
Designer and so forth.

There a ton of GUI APIs out there that almost none uses, is it because they
are not stable ?

Well ... *cough* Windows *cough* ... sure.

Making GUIs via code, is not as much fun, its slower and ends up being also
less flexible as you can easily lose track of what you intend to do trying
to understand the internals of a GUI API. Not fun at all. Especially if you
experienced the horrors of MFC.

But I am realistic , don't expect a GUI designer any time soon in Pharo.
They are very hard to make and coders being allergic to GUIs does not help
motivate to make one.

I am ok with just a modular image format.

Also I drink my own poison. I have made my own GUI API in Python with
OpenGL (used from inside Blender for an application I am developing) very
loosely inspired by some things I liked about Morphic. The more complex it
becomes the more I feel the need to create a designer that will handle the
boring stuff for me.

For now I use the excellent excuse you provide of stability and inability
to promise the structure of the GUI API in the future. But its an excuse
with an expiration date. Making the GUI I have in my head using plain code
, without a GUI designer, is a nightmare that is highly unlikely I will let
myself experience.

On the other hand when one makes his own GUI API the good news is that he
can make it fits well in the workflow of a GUI designer. This way instead
of trying to make the Designer according to the API , I make the API
according to the designer.

But the good news is that it has helped me realize the amount work needed
to put in GUI API to become really useful. Fortunately making API to find
only my needs has made things far easier and far smaller. I cannot imagine
making something like Bloc and keeping my sanity. This way the next time I
complain about a GUI API, I will have a whole different level of respect
for the developers behind it.
s***@gmail.com
2017-12-25 22:06:50 UTC
Permalink
Yes we talk about something like that with Clément some months ago.

Envoyé de mon iPhone
Post by Torsten Bergmann
A GUI builder is always a nice thing ... and there already was an attempt
http://www.squeaksource.com/UIBuilder/
Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. That version
only works in Pharo 1.1. Is opened for any developer.".
Dont know why it failed ... maybe because the UI (especially with Morphic legacy)
is still too shaky are in Pharo.
- good and stable graphics framework (maybe solved with Bloc)
- good and stable standardized widget set (maybe solved with Brick)
- then place a UI builder on top of it
Bye
Yeap that's the ideology about GUI designers , which is why so few IDE's have them. It's like the man waiting for the perfect woman to marry, ending up all alone and miserable.
As a designer myself I cannot follow easily this ideology. Actually I cannot follow it at all.
I see it the exact opposite way, if you don't have a good GUI designer , your ability to provide a stable and powerful GUI API will be limited because less people will use it.
The most stable and powerful GUI api I ever used was VCL , the standard library of Delphi and surprise, surprise it has a GUI designer. The most powerful I used so far.
Open source wise QT dominates , surprise , surprise it has a very powerful GUI designer.
On Windows you have VS studio GUI designer on MacOS and iOS the XCode GUI Designer and so forth.
There a ton of GUI APIs out there that almost none uses, is it because they are not stable ?
Well ... *cough* Windows *cough* ... sure.
Making GUIs via code, is not as much fun, its slower and ends up being also less flexible as you can easily lose track of what you intend to do trying to understand the internals of a GUI API. Not fun at all. Especially if you experienced the horrors of MFC.
But I am realistic , don't expect a GUI designer any time soon in Pharo. They are very hard to make and coders being allergic to GUIs does not help motivate to make one.
I am ok with just a modular image format.
Also I drink my own poison. I have made my own GUI API in Python with OpenGL (used from inside Blender for an application I am developing) very loosely inspired by some things I liked about Morphic. The more complex it becomes the more I feel the need to create a designer that will handle the boring stuff for me.
For now I use the excellent excuse you provide of stability and inability to promise the structure of the GUI API in the future. But its an excuse with an expiration date. Making the GUI I have in my head using plain code , without a GUI designer, is a nightmare that is highly unlikely I will let myself experience.
On the other hand when one makes his own GUI API the good news is that he can make it fits well in the workflow of a GUI designer. This way instead of trying to make the Designer according to the API , I make the API according to the designer.
But the good news is that it has helped me realize the amount work needed to put in GUI API to become really useful. Fortunately making API to find only my needs has made things far easier and far smaller. I cannot imagine making something like Bloc and keeping my sanity. This way the next time I complain about a GUI API, I will have a whole different level of respect for the developers behind it.
Stephane Ducasse
2017-12-25 14:51:40 UTC
Permalink
Hi hilaire

what is nice is that we have most of the same wishes ;)
Post by Hilaire
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo
Esteban!) and commit to arbitrary repository, experimenting it with DrGeo,
and it is nice to commit code[1] along other data files of the project
(graphics, doc, translation, etc.). Got some an when non ascii characters
were present in the source code, people reported it there. Likely to be
fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at some
time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
All these wishes are under construction, so likely to happen \o/
I have personal three wishes (beside good health of course), sharing it in
A. get DrGeo working on P7, particularly on the bootstrap process.
B. Build an environment in Pharo to develop simple games, targeted for kids.
There are some teenagers in my school likely to get interested on such
courses. If it could result in standalone games build thanks to wish 4., so
good.
C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods (can't
get the right tooling to do geometry for example), handwriting is not nice,
hacking on it is super complicated (C++ code), not to mention the building
process. A Pharo based one will be fantastic and much easy to hack.
Have a nice Christmas!
[1]
http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/
[2] http://openboard.ch
Post by Esteban Lorenzano
So, let’s those wishes come!
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-25 14:57:04 UTC
Permalink
Post by Hilaire
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo
Esteban!) and commit to arbitrary repository, experimenting it with DrGeo,
and it is nice to commit code[1] along other data files of the project
(graphics, doc, translation, etc.). Got some an when non ascii characters
were present in the source code, people reported it there. Likely to be
fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at some
time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some ;-)
We would like the same. Now spec was an increment in that direction
because behind the UI builder you need to reuse the model. So
with a pass on spec we will be set to be able to build the builder part
Post by Hilaire
5. fulfill the promise of tiny image, aka bootstrap and 4.
Did you see that pavel produced a smaller image than the first
bootstrapped version
Post by Hilaire
All these wishes are under construction, so likely to happen \o/
I have personal three wishes (beside good health of course), sharing it in
A. get DrGeo working on P7, particularly on the bootstrap process.
Let us know the problem you face because this is important that you can.
Post by Hilaire
B. Build an environment in Pharo to develop simple games, targeted for kids.
There are some teenagers in my school likely to get interested on such
courses. If it could result in standalone games build thanks to wish 4., so
good.
I'm interested into that this is why I proposed to "laura"
maximilliano to work on such framework.
Now I never got the time to do a pass over it and to release what I learned.
- direction
- handling on moves.
- I created a grid data structure but this is the least interesting part.

If you want we can discuss what I learned.
Also students in Prague are building games on top of Bloc.
Post by Hilaire
C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods (can't
get the right tooling to do geometry for example), handwriting is not nice,
hacking on it is super complicated (C++ code), not to mention the building
process. A Pharo based one will be fantastic and much easy to hack.
Is Pharo running on this?
Post by Hilaire
Have a nice Christmas!
[1]
http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/
[2] http://openboard.ch
Post by Esteban Lorenzano
So, let’s those wishes come!
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-25 17:25:33 UTC
Permalink
I really don't mean a GUI builder :-)
Post by Stephane Ducasse
Post by Hilaire
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at some
time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some;-)
We would like the same. Now spec was an increment in that direction
because behind the UI builder you need to reuse the model. So
with a pass on spec we will be set to be able to build the builder part
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-26 20:29:43 UTC
Permalink
Yes saw and my second answer took that into account. We were
discussing about making sure that we can write applications vs. code.
We should be able to package an application.
The experience accumulated with the launcher and the effort on making
Pharo silent (not forcing to write everywhere files)
are in that direction too.

Stef
Post by Hilaire
I really don't mean a GUI builder :-)
Post by Stephane Ducasse
Post by Hilaire
4. application builder. Smalltalk/X has a GUI to build a standalone
application, was not able to get it working, but it probably worked at some
time in the past (see screenshot). Such a feature in Pharo will be
fantastic, and likely a kill feature for the ones developing stand alone
application; yes there are still some;-)
We would like the same. Now spec was an increment in that direction
because behind the UI builder you need to reuse the model. So
with a pass on spec we will be set to be able to build the builder part
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-25 17:51:27 UTC
Permalink
Let's discuss it in another thread.

Until now, I moved slowly to update the drgeo build script to adjust to
Tonel file repository and P7; mostly done now. Will now look for help
from Pavel to build the drgeo image from a tiny core.

About the other problems to get a user ready drgeo application based on
the forthcoming P7:

- set up an application 64bits VMs architecture for Linux, OS X and
Windows (aka one-click image). I understand the later may be a problem
as there is not yet 64bits VMs.

- get over the strange oddities appearing with P7, long and tedious but
mandatory; otherwise this sets back drgeo as an end user (student,
teacher)  will immediately run away if drgeo is unpredictable. It really
took me a long time to get drgeo right on P3 because these oddities only
show up at runtime, under specific scenario. There are easy to fix,
thought. Writing more tests should help too.

Hilaire
Post by Stephane Ducasse
Post by Hilaire
5. fulfill the promise of tiny image, aka bootstrap and 4.
Did you see that pavel produced a smaller image than the first
bootstrapped version
Post by Hilaire
All these wishes are under construction, so likely to happen \o/
I have personal three wishes (beside good health of course), sharing it in
A. get DrGeo working on P7, particularly on the bootstrap process.
Let us know the problem you face because this is important that you can.
--
Dr. Geo
http://drgeo.eu
Ben Coman
2017-12-25 22:59:34 UTC
Permalink
Post by Hilaire
Let's discuss it in another thread.
Until now, I moved slowly to update the drgeo build script to adjust to
Tonel file repository and P7; mostly done now. Will now look for help from
Pavel to build the drgeo image from a tiny core.
About the other problems to get a user ready drgeo application based on
- set up an application 64bits VMs architecture for Linux, OS X and
Windows (aka one-click image). I understand the later may be a problem as
there is not yet 64bits VMs.
- get over the strange oddities appearing with P7, long and tedious but
mandatory; otherwise this sets back drgeo as an end user (student,
teacher) will immediately run away if drgeo is unpredictable. It really
took me a long time to get drgeo right on P3 because these oddities only
show up at runtime, under specific scenario. There are easy to fix,
thought. Writing more tests should help too.
It would be great to have Issues opened with new tests attached for these
specific cases
that currently fail which we can work on make green.
They make the problem nicely explicit to work on.

cheers -ben
Post by Hilaire
Hilaire
Post by Hilaire
5. fulfill the promise of tiny image, aka bootstrap and 4.
Did you see that pavel produced a smaller image than the first
bootstrapped version
All these wishes are under construction, so likely to happen \o/
Post by Hilaire
I have personal three wishes (beside good health of course), sharing it in
A. get DrGeo working on P7, particularly on the bootstrap process.
Let us know the problem you face because this is important that you can.
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-26 10:51:25 UTC
Permalink
I meant more tests in DrGeo to expose its features, and to discover
where newer Pharo breaks it.

Hilaire
really took me a long time to get drgeo right on P3 because these
oddities only show up at runtime, under specific scenario. There
are easy to fix, thought. Writing more tests should help too.
It would be great to have Issues opened with new tests attached for
these specific cases
that currently fail which we can work on make green.
They make the problem nicely explicit to work on.
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-25 17:58:52 UTC
Permalink
You may have different kind of games; for example in 2D games, it could
be fixed frame, side scrolling, up scrolling, isometric, etc. To get it
started easily, it could come with graphic and audio banks.

I really don't have much idea how such a general system should be
designed. Only wrote once a commercial decades ago on ARM code.

Will look a the bloc tutorial for game[1]

[1] https://github.com/pharo-graphics/Tutorials/
Post by Stephane Ducasse
Post by Hilaire
B. Build an environment in Pharo to develop simple games, targeted for kids.
There are some teenagers in my school likely to get interested on such
courses. If it could result in standalone games build thanks to wish 4., so
good.
I'm interested into that this is why I proposed to "laura"
maximilliano to work on such framework.
Now I never got the time to do a pass over it and to release what I learned.
- direction
- handling on moves.
- I created a grid data structure but this is the least interesting part.
If you want we can discuss what I learned.
Also students in Prague are building games on top of Bloc.
--
Dr. Geo
http://drgeo.eu
Clément Bera
2017-12-25 18:32:38 UTC
Permalink
See those ReadMe:

https://github.com/clementbera/wizard-battle-arena

https://github.com/clementbera/SpiderInvasion

Audio has always been a problem to me. I successfully run audio files with
the open AL binding, but I failed to do so cross-platform. Already
key-bindings coherent cross platform is difficult.

Cheers
You may have different kind of games; for example in 2D games, it could be
fixed frame, side scrolling, up scrolling, isometric, etc. To get it
started easily, it could come with graphic and audio banks.
I really don't have much idea how such a general system should be
designed. Only wrote once a commercial decades ago on ARM code.
Will look a the bloc tutorial for game[1]
[1] https://github.com/pharo-graphics/Tutorials/
Post by Hilaire
B. Build an environment in Pharo to develop simple games, targeted for
Post by Hilaire
kids.
There are some teenagers in my school likely to get interested on such
courses. If it could result in standalone games build thanks to wish 4., so
good.
I'm interested into that this is why I proposed to "laura"
maximilliano to work on such framework.
Now I never got the time to do a pass over it and to release what I learned.
- direction
- handling on moves.
- I created a grid data structure but this is the least interesting part.
If you want we can discuss what I learned.
Also students in Prague are building games on top of Bloc.
--
Dr. Geo
http://drgeo.eu
--
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Hilaire
2017-12-26 15:19:43 UTC
Permalink
Read. SDL + Cairo is the way you have been. I did not imagine Cairo was
good at manipulating block of bitmap.

Is Cairo stable over time in Pharo? I wonder will it be wiped out. More
generally, I wonder what is the stable ground to build graphic
application on Pharo?
Post by Clément Bera
https://github.com/clementbera/wizard-battle-arena
https://github.com/clementbera/SpiderInvasion
Audio has always been a problem to me. I successfully run audio files
with the open AL binding, but I failed to do so cross-platform.
Already key-bindings coherent cross platform is difficult.
Cheers
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-26 20:34:06 UTC
Permalink
Hi Hilaire

yes you can have multiple approaches. I was focusing on tiles-based
ones: sokoban, miners..
SDL2.0 is our plan.
For Cairo we asked Bloc guys to make sure that we can use Cairo as
back end to avoid to have 20 mb by default
with Mozz2d (and mozz2d is not really packaged by their creators so
high risk) so Cairo should stay around.

Now I would like to use Bloc for tile based games.
Stef
Read. SDL + Cairo is the way you have been. I did not imagine Cairo was good
at manipulating block of bitmap.
Is Cairo stable over time in Pharo? I wonder will it be wiped out. More
generally, I wonder what is the stable ground to build graphic application
on Pharo?
Post by Clément Bera
https://github.com/clementbera/wizard-battle-arena
https://github.com/clementbera/SpiderInvasion
Audio has always been a problem to me. I successfully run audio files with
the open AL binding, but I failed to do so cross-platform. Already
key-bindings coherent cross platform is difficult.
Cheers
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-28 15:39:16 UTC
Permalink
What is the reason using Cairo over SDSL? Is not SDL just enought?

Hilaire
Post by Clément Bera
https://github.com/clementbera/wizard-battle-arena
https://github.com/clementbera/SpiderInvasion
Audio has always been a problem to me. I successfully run audio files
with the open AL binding, but I failed to do so cross-platform.
Already key-bindings coherent cross platform is difficult.
--
Dr. Geo
http://drgeo.eu
Clément Bera
2017-12-28 17:51:43 UTC
Permalink
Post by Hilaire
What is the reason using Cairo over SDSL? Is not SDL just enought?
My understanding is that SDL provides the surface to draw on as part of the
window, but not a 2D vector graphic engine on top. You've got only draw
Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want
for games on the SDL surface, the normal way is to use a third party
library such as Cairo.

For 3D I believe people use SDL combined with open GL or direct3D instead
of Cairo but I don't know the details.

For events (keyboard, mouse, joypad) I use SDL event management and it
works differently on each OS. I wrote in the readMe the different set-ups
to make it work on each OS. On Windows and Linux I can use the latest
Pharo. On Mac I use old Pharo 5 images.

I guess it's possible to use SDL for audio, but it seems there is no code
relative to audio in the SDL binding and in OSWindow in Pharo. That's why I
did not go that way. I tried multiple things but I successfully run audio
code in Pharo only with the openAL binding and .wav file (and even in this
case, I had to install external librairies in Mac OS...).

Whichever if Cairo stays around or not does not really matter, normally one
uses Cairo through Athens or Sparta, abstraction layers on top of 2D
graphic engines. I've worked with other 2D engines and the API are always
almost the same, so I have no doubt that if Cairo support is dropped we can
re-bind Athens/Sparta with another 2D engine (such as engines used by web
browsers).
Post by Hilaire
Hilaire
Post by Clément Bera
https://github.com/clementbera/wizard-battle-arena
https://github.com/clementbera/SpiderInvasion
Audio has always been a problem to me. I successfully run audio files
with the open AL binding, but I failed to do so cross-platform. Already
key-bindings coherent cross platform is difficult.
--
Dr. Geo
http://drgeo.eu
--
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Dimitris Chloupis
2017-12-30 06:02:06 UTC
Permalink
Problem is that people , coders and users, tend to underestimate the
complexity of game development.

99% of the technology we use nowadays is game based.

Powerful GPUs utilized by consumer computers and supercomputer alike to
deal with highly complex problems like cancer research and simulations of
the Bing Bang.

Massive memory that is millions time large than technology that existed 30
years ago. A computer with 128GB of memory is exactly 1 million times
bigger than my first computer with 128 kbs of memory that will become 30
years old in exactly one year.

Massive super fast hard drives.

Multi core CPUs

The internet.

Anything you look around you has so massively progressed , only because of
high end games that have created the most profitable business for half a
century. No other kind of software comes remotely close to pushing the
hardware to such extremes and yet being so massively popular as high end
games.

So game APIs are extremely complex even for the simplest games. In Python
for example we have , or rather had , Pygame , it’s as massively popular
with beginners game developers as its massively unpopular with profession
or very experienced amateur game developers. The latest Pygame is basically
SDL with some extra game stuff.

Why people don’t use it beyond proof of concept ?

One word

“Simple”

What the rest of the computer world pursue as the holy grail in game
development is nothing more than a bad allergy .

Why ?

Because You will be far better in embracing the extremely complex engines
on the market even for the creation of the simplest games. The moment you
decide that using such an engine is an overkill for your so simple needs
and that you don’t have to endure their very steep learning curve is the
moment you condemn yourself to a full rewrite if there is a remote chance
of taking the game one step further.

We all know how much fun full rewrites are.

In short making games is no game.

Go use a professional engine and you can thank me later.
Post by Clément Bera
Post by Hilaire
What is the reason using Cairo over SDSL? Is not SDL just enought?
My understanding is that SDL provides the surface to draw on as part of
the window, but not a 2D vector graphic engine on top. You've got only draw
Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want
for games on the SDL surface, the normal way is to use a third party
library such as Cairo.
For 3D I believe people use SDL combined with open GL or direct3D instead
of Cairo but I don't know the details.
For events (keyboard, mouse, joypad) I use SDL event management and it
works differently on each OS. I wrote in the readMe the different set-ups
to make it work on each OS. On Windows and Linux I can use the latest
Pharo. On Mac I use old Pharo 5 images.
I guess it's possible to use SDL for audio, but it seems there is no code
relative to audio in the SDL binding and in OSWindow in Pharo. That's why I
did not go that way. I tried multiple things but I successfully run audio
code in Pharo only with the openAL binding and .wav file (and even in this
case, I had to install external librairies in Mac OS...).
Whichever if Cairo stays around or not does not really matter, normally
one uses Cairo through Athens or Sparta, abstraction layers on top of 2D
graphic engines. I've worked with other 2D engines and the API are always
almost the same, so I have no doubt that if Cairo support is dropped we can
re-bind Athens/Sparta with another 2D engine (such as engines used by web
browsers).
Post by Hilaire
Hilaire
Post by Clément Bera
https://github.com/clementbera/wizard-battle-arena
https://github.com/clementbera/SpiderInvasion
Audio has always been a problem to me. I successfully run audio files
with the open AL binding, but I failed to do so cross-platform. Already
key-bindings coherent cross platform is difficult.
--
Dr. Geo
http://drgeo.eu
--
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650
<https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve
d
<https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>
'Ascq
<https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>
Hilaire
2017-12-30 20:33:04 UTC
Permalink
I found the mix of OSWindow+SDL+Athens very complex (tens of classes
with hundreds of methods) and to produce code hard to understand (I look
at your spider code).

I will prefer fewer functionnality I can understand.

For example, how can you copy a sprite on a SDL surface? Can you do it
without Athens surface?
Post by Clément Bera
Whichever if Cairo stays around or not does not really matter,
normally one uses Cairo through Athens or Sparta, abstraction layers
on top of 2D graphic engines. I've worked with other 2D engines and
the API are always almost the same, so I have no doubt that if Cairo
support is dropped we can re-bind Athens/Sparta with another 2D engine
(such as engines used by web browsers).
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-30 21:32:30 UTC
Permalink
Hilaire

why do you need to have a sprite on a SDL surface and why plain Athens
is not good enough. Athens is an API not an implementation.
It is like sparta: an API and you do not care about the library below.

OSWindow is a layer on top of SDL and it is better than SDL directly
to my understanding.
So you should get Athens and SDL for event.

What kind of game are you targeting? Did you look at Bloc? Because to
me this is the way to go except if you want just a canvas
and reimplement your event loop. in that case SDL + Athens should work.

Stef
I found the mix of OSWindow+SDL+Athens very complex (tens of classes with
hundreds of methods) and to produce code hard to understand (I look at your
spider code).
I will prefer fewer functionnality I can understand.
For example, how can you copy a sprite on a SDL surface? Can you do it
without Athens surface?
Post by Clément Bera
Whichever if Cairo stays around or not does not really matter, normally
one uses Cairo through Athens or Sparta, abstraction layers on top of 2D
graphic engines. I've worked with other 2D engines and the API are always
almost the same, so I have no doubt that if Cairo support is dropped we can
re-bind Athens/Sparta with another 2D engine (such as engines used by web
browsers).
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-31 13:14:54 UTC
Permalink
because simple things should be simple...
Post by Hilaire
Hilaire
why do you need to have a sprite on a SDL surface and why plain Athens
is not good enough. Athens is an API not an implementation.
It is like sparta: an API and you do not care about the library below.
OSWindow is a layer on top of SDL and it is better than SDL directly
to my understanding.
So you should get Athens and SDL for event.
What kind of game are you targeting? Did you look at Bloc? Because to
me this is the way to go except if you want just a canvas
and reimplement your event loop. in that case SDL + Athens should work.
Stef
I found the mix of OSWindow+SDL+Athens very complex (tens of classes with
hundreds of methods) and to produce code hard to understand (I look at your
spider code).
I will prefer fewer functionnality I can understand.
For example, how can you copy a sprite on a SDL surface? Can you do it
without Athens surface?
Post by Clément Bera
Whichever if Cairo stays around or not does not really matter, normally
one uses Cairo through Athens or Sparta, abstraction layers on top of 2D
graphic engines. I've worked with other 2D engines and the API are always
almost the same, so I have no doubt that if Cairo support is dropped we can
re-bind Athens/Sparta with another 2D engine (such as engines used by web
browsers).
--
Dr. Geo
http://drgeo.eu
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-31 13:41:57 UTC
Permalink
I am *exploring* if Pharo will be suitable to have a simple programming
environment to let kids write simple 2D games, SDL was designed for that.

Some of my students asked me about programming games, Smalltalk way of
writing code will be neat, but the environment need to be accessible and
not over engineered.
Post by Stephane Ducasse
What kind of game are you targeting? Did you look at Bloc? Because to
me this is the way to go except if you want just a canvas
and reimplement your event loop. in that case SDL + Athens should work.
--
Dr. Geo
http://drgeo.eu
Stephane Ducasse
2017-12-31 23:00:28 UTC
Permalink
Hi hilaire

Some students at Prague are working on different 2D games with Bloc
and this is working.
Some did a sokoban, other a miner (check on pharo weekly).

They use Bloc and I will ask them to make public their code.
No need for SDL. SDL is ***low level***.

Now modeling the board and proposing some abstractions that can be
easily extended is difficult.
and this is what lauraMaximilliano did in MetaBorg.

It was on my todo to do a pass. I implemented a grid to help the
design of board game.
Now having direction/location can be good.

What is interesting in the design of metaborg is that we do not test
if an object can move to
a place. We go to the place and the place pull the item.
A wall will not pull for example while a empty slot will pull the item to move.

I found it intriguing and I would like to know if this is working for
more complex situation.

Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork.
Now it is a bit abstract but an interesting experience.


Stef
Post by Hilaire
I am *exploring* if Pharo will be suitable to have a simple programming
environment to let kids write simple 2D games, SDL was designed for that.
Some of my students asked me about programming games, Smalltalk way of
writing code will be neat, but the environment need to be accessible and not
over engineered.
Post by Stephane Ducasse
What kind of game are you targeting? Did you look at Bloc? Because to
me this is the way to go except if you want just a canvas
and reimplement your event loop. in that case SDL + Athens should work.
--
Dr. Geo
http://drgeo.eu
Hilaire
2018-01-01 16:50:54 UTC
Permalink
Hi Stef,

A complete port of the SDL capabilities
(http://wiki.libsdl.org/Introduction) will be super nice (audio) and
improved stability.

For your students, the perspective on the game is likely 2 months, may
be 6 months; you know I have longer perspective - DrGeo was slowly
developed and crafted for 20 years; therefore stability on the code is
very important for me as I will have to work over long period. That's
the reason I don't fell at ease relying on many code layers. For your
students, as the horizon is counted in months it is a null
consideration, not for me. Not to mention there are uncertainty over
this layers. Moreover these layers will make hard to my student to
understand what's going on, if they want to dig in.

I am not sure how far will get me this reflexion, but for my students, I
can imagine different models of 2D games: board games,
horizontal/vertical scrolling games, isometric games. Each one can be
optimized differently. Banks of sprites and audio will be already there
to get started the students. The models will encapsulate SDL, as PyGame
is doing, but still easilly accessible.

I imagine such an environment to rely only on two layers: SDL and spec,
the later if some dedicated user interface is needed for the game
designer; but a lot should happen in the class browser.

I found this Python PyGame code bellow rather easy to understand. Will
it be possible to produce an equally understandable Smalltalk code with
the layers your are proposing?

importsys,pygamepygame.init()size=width,height=320,240speed=[2,2]black=0,0,0screen=pygame.display.set_mode(size)ball=pygame.image.load("ball.bmp")ballrect=ball.get_rect()while1:foreventinpygame.event.get():ifevent.type==pygame.QUIT:sys.exit()ballrect=ballrect.move(speed)ifballrect.left<0orballrect.right>width:speed[0]=-speed[0]ifballrect.top<0orballrect.bottom>height:speed[1]=-speed[1]screen.fill(black)screen.blit(ball,ballrect)pygame.display.flip()


Hilaire

Your time stamp bellow is a strike! ;)
   vvvvvvvvvvvvvvvvvvvvvv
Post by Stephane Ducasse
Hi hilaire
Some students at Prague are working on different 2D games with Bloc
and this is working.
Some did a sokoban, other a miner (check on pharo weekly).
They use Bloc and I will ask them to make public their code.
No need for SDL. SDL is ***low level***.
Now modeling the board and proposing some abstractions that can be
easily extended is difficult.
and this is what lauraMaximilliano did in MetaBorg.
It was on my todo to do a pass. I implemented a grid to help the
design of board game.
Now having direction/location can be good.
What is interesting in the design of metaborg is that we do not test
if an object can move to
a place. We go to the place and the place pull the item.
A wall will not pull for example while a empty slot will pull the item to move.
I found it intriguing and I would like to know if this is working for
more complex situation.
Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork.
Now it is a bit abstract but an interesting experience.
Stef
I am*exploring* if Pharo will be suitable to have a simple programming
environment to let kids write simple 2D games, SDL was designed for that.
Some of my students asked me about programming games, Smalltalk way of
writing code will be neat, but the environment need to be accessible and not
over engineered.
Post by Stephane Ducasse
What kind of game are you targeting? Did you look at Bloc? Because to
me this is the way to go except if you want just a canvas
and reimplement your event loop. in that case SDL + Athens should work.
--
Dr. Geo
http://drgeo.eu
--
Dr. Geo
http://drgeo.eu
Hilaire
2018-01-01 16:56:09 UTC
Permalink
Stephane Ducasse
2018-01-02 20:38:18 UTC
Permalink
This code can be just in a method of subclass of BlGameElement.
You should really try because Bloc is really nice.
And this is not a layer this is the future Morphic.

Now if you work on SDL instead of Athens (remember Athens is an API)
when we will change SDL for the
next low level framework you will have to change.

Stef
Post by Hilaire
Hi Stef,
A complete port of the SDL capabilities
(http://wiki.libsdl.org/Introduction) will be super nice (audio) and
improved stability.
For your students, the perspective on the game is likely 2 months, may be 6
months; you know I have longer perspective - DrGeo was slowly developed and
crafted for 20 years; therefore stability on the code is very important for
me as I will have to work over long period. That's the reason I don't fell
at ease relying on many code layers. For your students, as the horizon is
counted in months it is a null consideration, not for me. Not to mention
there are uncertainty over this layers. Moreover these layers will make hard
to my student to understand what's going on, if they want to dig in.
I am not sure how far will get me this reflexion, but for my students, I can
imagine different models of 2D games: board games, horizontal/vertical
scrolling games, isometric games. Each one can be optimized differently.
Banks of sprites and audio will be already there to get started the
students. The models will encapsulate SDL, as PyGame is doing, but still
easilly accessible.
I imagine such an environment to rely only on two layers: SDL and spec, the
later if some dedicated user interface is needed for the game designer; but
a lot should happen in the class browser.
I found this Python PyGame code bellow rather easy to understand. Will it be
possible to produce an equally understandable Smalltalk code with the layers
your are proposing?
importsys,pygamepygame.init()size=width,height=320,240speed=[2,2]black=0,0,0screen=pygame.display.set_mode(size)ball=pygame.image.load("ball.bmp")ballrect=ball.get_rect()while1:foreventinpygame.event.get():ifevent.type==pygame.QUIT:sys.exit()ballrect=ballrect.move(speed)ifballrect.left<0orballrect.right>width:speed[0]=-speed[0]ifballrect.top<0orballrect.bottom>height:speed[1]=-speed[1]screen.fill(black)screen.blit(ball,ballrect)pygame.display.flip()
Hilaire
Your time stamp bellow is a strike! ;)
vvvvvvvvvvvvvvvvvvvvvv
Post by Stephane Ducasse
Hi hilaire
Some students at Prague are working on different 2D games with Bloc
and this is working.
Some did a sokoban, other a miner (check on pharo weekly).
They use Bloc and I will ask them to make public their code.
No need for SDL. SDL is ***low level***.
Now modeling the board and proposing some abstractions that can be
easily extended is difficult.
and this is what lauraMaximilliano did in MetaBorg.
It was on my todo to do a pass. I implemented a grid to help the
design of board game.
Now having direction/location can be good.
What is interesting in the design of metaborg is that we do not test
if an object can move to
a place. We go to the place and the place pull the item.
A wall will not pull for example while a empty slot will pull the item to move.
I found it intriguing and I would like to know if this is working for
more complex situation.
Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork.
Now it is a bit abstract but an interesting experience.
Stef
I am*exploring* if Pharo will be suitable to have a simple programming
environment to let kids write simple 2D games, SDL was designed for that.
Some of my students asked me about programming games, Smalltalk way of
writing code will be neat, but the environment need to be accessible and not
over engineered.
Post by Stephane Ducasse
What kind of game are you targeting? Did you look at Bloc? Because to
me this is the way to go except if you want just a canvas
and reimplement your event loop. in that case SDL + Athens should work.
--
Dr. Geo
http://drgeo.eu
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-28 15:43:44 UTC
Permalink
IF there is a Pharo binding for SDL, why not audio from SDSL?
Post by Clément Bera
Audio has always been a problem to me. I successfully run audio files
with the open AL binding, but I failed to do so cross-platform.
Already key-bindings coherent cross platform is difficult.
--
Dr. Geo
http://drgeo.eu
Hilaire
2017-12-25 18:04:51 UTC
Permalink
I don't understand your question
Post by Stephane Ducasse
Post by Hilaire
C. Develop a white board application, easy to extend to add third party
features. The OpenBoard[2] we are using in school are merely goods (can't
get the right tooling to do geometry for example), handwriting is not nice,
hacking on it is super complicated (C++ code), not to mention the building
process. A Pharo based one will be fantastic and much easy to hack.
Is Pharo running on this?
--
Dr. Geo
http://drgeo.eu
Evan Donahue
2017-12-25 17:55:20 UTC
Permalink
Given the recent stirrings of AI-related applications in Pharo, I guess I'm
wishing for vm support for vector operations/fast math. I heard something
about that a while ago on the polymath chanel, so I figure it can't hurt to
wish.

Evan



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Stephane Ducasse
2017-12-26 20:30:18 UTC
Permalink
Hi Evan

yes thierry was discussing with clement and we will see :).

Stef
Post by Evan Donahue
Given the recent stirrings of AI-related applications in Pharo, I guess I'm
wishing for vm support for vector operations/fast math. I heard something
about that a while ago on the polymath chanel, so I figure it can't hurt to
wish.
Evan
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Bernhard Pieber
2017-12-27 16:11:18 UTC
Permalink
Hi Esteban,

Thanks for asking. My one and only wish is more stability for the stable version, i.e. bug fixes for Pharo 6, especially the VMs but also the image.

Thanks for Pharo!

Cheers,
Bernhard
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc…. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
Stéphane Ducasse
2017-12-30 12:15:03 UTC
Permalink
nice list :)
- stable 64bit vm
- mature iceberg plus dependent tools
- no endless loop in debugging anymore aka real stoppable computation
- bootstrap aka small image
- vm with collaboration support
- working SSL on newer distributions
- unified keymapping
- improved epicea
- better parser support aka core petit parser in the image
- basic document model in the image for documentation aka mini pillar
- bloc plus basic widgets
- better modification tracking support
- runtime traits / dynamic layers
- better set of slot classes for types and relations
Norbert
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
Holger Freyther
2017-12-30 14:51:05 UTC
Permalink
Hey!
- working SSL on newer distributions
related to that I would love a working VM release process.

- Tag releases of the stable VM
- Be able to take release X.Y and release X.Y+1 with a single bugfix
Stéphane Ducasse
2017-12-30 16:25:50 UTC
Permalink
Me too :)
Post by Holger Freyther
Hey!
- working SSL on newer distributions
related to that I would love a working VM release process.
- Tag releases of the stable VM
- Be able to take release X.Y and release X.Y+1 with a single bugfix
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
Stephan Eggermont
2017-12-31 11:58:19 UTC
Permalink
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would
you want to see in Pharo next year.
I wish you all the time and good health to realize some of your Pharo
dreams

Stephan
Stephane Ducasse
2017-12-31 22:40:59 UTC
Permalink
Tx Stephan
I have too many dreams :) so I will have to prioritize but let's the
first three :).

Stef
Post by Stephan Eggermont
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would
you want to see in Pharo next year.
I wish you all the time and good health to realize some of your Pharo
dreams
Stephan
Petr Fischer
2018-01-02 22:05:33 UTC
Permalink
- stability
- bloc
- some sort of pretty cool and fast concurrent transactional object persistence :)
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
Features, improvements, radical changes, etc…. whatever you want.
Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
So, let’s those wishes come!
cheers,
Esteban
Ben Coman
2018-01-05 01:58:57 UTC
Permalink
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you
want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
Of course, this list will not be a roadmap and it does not means we will
implement all of it (as always, time drives our possibilities), but is a
good moment for us a a community to check where we are and where we wan to
go next :)
So, let’s those wishes come!
Small enhancement that arises as I'm trying to design a Morph,
Initially forgetting which corner of the screen is ***@0, raises the idea
that in the GTInspector Morph tab,
showing the coordinates of the mouse as it tracks over the morph would be
useful.
Maybe this would be less useful for Morphic using absolute co-ordinates,
but good for Bloc using relative co-ordinates (IIUC).

cheers -ben
Ben Coman
2018-01-06 11:58:52 UTC
Permalink
Post by Esteban Lorenzano
Hi everybody,
This looks like a good moment of the year to ask all of you what would you
want to see in Pharo next year.
Features, improvements, radical changes, etc
. whatever you want.
Of course, this list will not be a roadmap and it does not means we will
implement all of it (as always, time drives our possibilities), but is a
good moment for us a a community to check where we are and where we wan to
go next :)
So, let’s those wishes come!
cheers,
Esteban
IIUC, our continuous integration system really only checks that "new" error
are not introduced.
This seems of limited facility to encourage dealing with existing errors.
So my wish is for...
1. TestRunner GUI results to be kept fault free.
2. Periodically scheduled human-driven reality check of [1.]

cheers -ben

Loading...