New Year Wishlist (2018) ?

I don't understand your question


Le 25/12/2017 à 15:57, Stephane Ducasse a écrit :
>> 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

Yes we talk about something like that with Clément some months ago.

On Mon, Dec 25, 2017 at 3:18 PM Torsten Bergmann <[hidden email]> wrote:

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

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. 

I meant more tests in DrGeo to expose its features, and to discover
where newer Pharo breaks it.

Hilaire

Le 25/12/2017 à 23:59, Ben Coman a écrit :
--
Dr. Geo
http://drgeo.eu

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?


Le 25/12/2017 à 19:32, Clément Bera a écrit :
--
Dr. Geo
http://drgeo.eu

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

On Mon, Dec 25, 2017 at 6:25 PM, Hilaire <[hidden email]> wrote:

Hi Evan

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

Stef

On Mon, Dec 25, 2017 at 6:55 PM, Evan Donahue <[hidden email]> wrote:

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


On Tue, Dec 26, 2017 at 4:19 PM, Hilaire <[hidden email]> wrote:

On 12/23/2017 06:57 PM, Cyril Ferlicot D. wrote: I also forgot: a real headless :)

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

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

What is the reason using Cairo over SDSL? Is not SDL just enought?

Hilaire


Le 25/12/2017 à 19:32, Clément Bera a écrit :
>
> 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

IF there is a Pharo binding for SDL, why not audio from SDSL?


Le 25/12/2017 à 19:32, Clément Bera a écrit :
> 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

On Wed, Dec 27, 2017 at 04:41:56PM +0100, Cyril Ferlicot D. wrote:
> 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

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.

nice list :)