Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2


On Sun, Sep 14, 2014 at 10:07 AM, Nicolai Hess <[hidden email]> wrote:
2014-09-14 18:20 GMT+02:00 kilon alios <[hidden email]>:
Plenty ? no 

A few ? yes

Woden is certainly a project that I want it to be successful and keep going forward but at the moment I can't say its usable when each time I resize the window it corrupts the viewport. 

No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more.

I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems.

This is definitly wrong :)
Especially the older squeak versions were ahead of its time with  (animated) interactive UI elements.
Java (Swing) does not come with an animation framework for the UI (JavaFX, yes but that took its time).
There was a timing/animation framework used by Roman Guy for its FilthyRich clients, that did really look great.
He created UIs that never looked like ordinary Java UIs. But I think that was done by few people only.
So, doing this for pharo should be doable. (I do remember something like that was done for
Morphic (maybe this one: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/animations))

yoiu can do great thinks with Qt for C++ simple animation with the good old qwidget and
the newer qml-framework. That's what I would call feature UIs (mostly what is done nowadays on mobile devices and other
"platforms" have their own frameworks (java)android and Object-C (IPhone).

And I think we will see more "feature"-UI on the web with HTML5/Canvas/Web-GL.

Do we need a good new UI framework for pharo? Yes.
Do we need many developers for working on this ? No, I think a handfull (2-4) people would be enough.
What pharo really needs are:
Many more developers *using* pharo as a platform.

Agreed.  But one real problem with the Squeak/Pharo UI is the lack of native windows.  There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used.  But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak.  The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically.  Is anyone motivated to port the Newspeak code back to Squeak/Pharo?


If you're interested, contact me, or Vassili, or Bob Westergaard and ask about Brazil (think plumbing).

nicolai


 

Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems.  I feel privileged to have helped you with my contributions , I wish the Pharo the best. 

I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo. 

In a few months I will also present to the Pharo community a secret last contribution ;) 

On Sun, Sep 14, 2014 at 6:26 PM, [hidden email] <[hidden email]> wrote:

Do you know anything better for futuristic UIs at the moment?

I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.

That being said, there are plenty of examples in the Woden code.

Phil

Le 14 sept. 2014 16:28, "Nicolai Hess" <[hidden email]> a écrit :

Why should he use it, now?
I mean, is there a stable API? Or a roadmap ?

Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks.
I did some work based on Roassal3D just to found out there won't be any further development.
The same happens with Roassal and GraphET.
The same can happen with Woden too :)





2014-09-14 14:13 GMT+02:00 [hidden email] <[hidden email]>:

Why not use Woden?

Phil

Le 14 sept. 2014 12:51, "kilon alios" <[hidden email]> a écrit :

yeah I am afraid transparency is very important to me 

On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <[hidden email]> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <[hidden email]>:
I remember that there was an animated gif support.
Now I do not remember exactly.

At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs.
That works and is quite fast even for multiple instances. But of course no (alpha-)transparency

 

for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.

Stef



On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code

form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'.
form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'.
v := RTView new.
c := v canvas.
s := TRBitmapShape new.
s form: form1.
c addShape: s.
v  open.

(1 to: 100) do: [ :index| 
s form: form1.
s signalUpdate .
"(Delay forMilliseconds: 1000 ) wait."
s form: form2.
s signalUpdate .
(Delay forMilliseconds: 1000) wait.].

I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ? 

if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect. 

On Sun, Sep 14, 2014 at 10:57 AM, stepharo <[hidden email]> wrote:
Ronie when you ready I can help writting a chapter for the nex book.

Stef


On 13/9/14 21:42, Ronie Salgado wrote:
Hello,

On 13/9/14 20:11, Enrico Schwass wrote:
Hi 

another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.

There is Wig like wrapper for Pharo done by ronie salgado.

I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig

Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig.
I still have to improve more my Swig generator, by writing documentation and fixing some bugs.

Greetings,
Ronie

2014-09-13 16:11 GMT-03:00 stepharo <[hidden email]>:

On 13/9/14 20:11, Enrico Schwass wrote:
Hi 

another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.

There is Wig like wrapper for Pharo done by ronie salgado.

Stef




Almost a decade ago I did some ruby bindings by hand. It was working out of the box

Bye
Enno

Am 13.09.2014 um 16:11 schrieb kilon alios <[hidden email]>:


" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "

yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file. 

So basically its a lot like the average games out there. 

"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."

ok 

"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."

I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is  procedural graphic format. Two opposite things. 

"Sure. The downpoint, you will depend on one additional layer."

dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.

"Nice.  What will be the expected outcomes of such API, I am not sure to understand and I am curious." 

Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically. 

So basically you will be using Blender as a GUI designer. 

"Use fuel to store the state of your application objects."

ah nice so fuel is a good candidate. 

I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) . 













--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2


On Mon, Sep 15, 2014 at 12:31 PM, Craig Latta <[hidden email]> wrote:

> ...one real problem with the Squeak/Pharo UI is the lack of native
> windows.  There is an old project Graphics-External-Ffenestri but
> AFAICT it isn't being used.

     I'm using it, on Mac OS so far (Windows and Ubuntu Linux are the
other host platforms I care about at the moment).

> But there /is/ a really good prototype of a native window system
> above Squeak done by Vassili Bykov in Newspeak.

     Hoooold on there... :)  Does this mean that Vassili tried Ffenestri
and found it unusable? If so, why? Details, please.

I don't want to talk for Vassili, but he had done the prototype for Pollock, the new window system for VW that was squandered by Cincom management.  In this he architected full conversion between native and non-native windows, both dynamically and over snapshot.  So when he came to implement the GUI for Newspeak he used that experience.  I don't see the same architectural support in  Graphics-External-Ffenestri it doesn't even support snapshot and resume on the same window system.  Here's the relevant extract from HostWIndowProxy's class comment:

"This is a proxy for a Host OS window and as such is considered a disposable item. When an image is restarted the client must recreate suitable instances from the information they hold."

So I expect Vassili didn't even think of using it.  Vassili's work doesn't need any VM support beyond the ability to ask the VM to /not/ respond to GUI events.  It is based on the FFI and uses callbacks to receive events.  In any case Vassili's work is the best candidate that I've ever seen for a proper native windows integration for Smalltalk systems that ave a history of non-native windows.


     thanks,

-C

--
Craig Latta
netjam.org
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)





--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

re: The Dilemma: Building a Futuristic GUI for Ephestos

ccrraaiigg

> ...I expect Vassili didn't even think of using it... In any case
> Vassili's work is the best candidate that I've ever seen for a proper
> native windows integration for Smalltalk systems that have a history
> of non-native windows.

     Fair enough. :) Thanks!


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

timrowledge
In reply to this post by Eliot Miranda-2
(this probably won’t get to the pharo list unless someone forwards it)

On 15-09-2014, at 12:40 PM, Eliot Miranda <[hidden email]> wrote:

>
>
> On Mon, Sep 15, 2014 at 12:31 PM, Craig Latta <[hidden email]> wrote:
>      Hoooold on there... :)  Does this mean that Vassili tried Ffenestri
> and found it unusable? If so, why? Details, please.
>
> I don't want to talk for Vassili, but he had done the prototype for Pollock, the new window system for VW that was squandered by Cincom management.  In this he architected full conversion between native and non-native windows, both dynamically and over snapshot.  So when he came to implement the GUI for Newspeak he used that experience.  I don't see the same architectural support in  Graphics-External-Ffenestri it doesn't even support snapshot and resume on the same window system.  

Absolutley. Ffenestri is/was just the basic low-level support that allowed host windows (and menus on windows/mac) to be used. John & I did it as part of the early work for Sophie and so far as I recall it never got actually used. Since people had been whining (loudly, frequently, and annoyingly) about how desperately host windows were needed we released the code with working trivial demos and … nothing. I don't think anybody ever even reported trying it out. This was around ten years ago, so evidently it was a really really urgent thing.

If there is actually functional code that can be adopted into Squeak we should go with it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CPM: Change Programmer's Mind



Reply | Threaded
Open this post in threaded view
|

re: The Dilemma: Building a Futuristic GUI for Ephestos

ccrraaiigg

> I don't think anybody ever even reported trying [Ffenestri].

     I did; it worked. And I just said so again a few messages ago. Hm.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: The Dilemma: Building a Futuristic GUI for Ephestos

timrowledge

On 15-09-2014, at 1:40 PM, Craig Latta <[hidden email]> wrote:

>
>> I don't think anybody ever even reported trying [Ffenestri].
>
>    I did; it worked. And I just said so again a few messages ago. Hm.

Well ok, but you’re hardly ‘anybody’. :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
When all else fails, let a = 7.  If that doesn't help, then read the manual.



Reply | Threaded
Open this post in threaded view
|

re: The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2
In reply to this post by ccrraaiigg
Hi Craig,

On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <[hidden email]> wrote:

> I don't think anybody ever even reported trying [Ffenestri].

     I did; it worked. And I just said so again a few messages ago. Hm.

OK.  It opens windows.  But a snippet in a workspace can do that.  It does not constitute a replacement for the current window system though does it?  But Vassili's work can be.  We had it in production at customer sites.  We could use it for development.  It was complete, in the sense that one could open arbitrary system windows as native windows, switch them back to "virtual" windows, snapshot etc and everything would keep working.  That's "working".  With great respect to Tim and John, their work in Ffenestri is not the same thing, is it?  By the same criteria I don't think what Qwaq did constituted a real system; it allowed the login WIndow to be displayed natively, but it didn't support development tools and it certainly didn't support snapshot or dynamic switching.  Being critical is not being insulting.  It's merely being objective.  At least I hope I'm being objective and not insulting anyone.  It is not my intent.

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Dilemma: Building a Futuristic GUI for Ephestos

Javier Diaz-Reinoso
In reply to this post by timrowledge
The problem with "new" code is you need some example/demo code, Ffenestri don't have that.

What about some demo code showing how you can send the "world menu" to the real mac menu bar, then I can adapt that demo in my own "apps".

On 15/09/2014, at 15:47, tim Rowledge <[hidden email]> wrote:

>
> On 15-09-2014, at 1:40 PM, Craig Latta <[hidden email]> wrote:
>
>>
>>> I don't think anybody ever even reported trying [Ffenestri].
>>
>>   I did; it worked. And I just said so again a few messages ago. Hm.
>
> Well ok, but you’re hardly ‘anybody’. :-)
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> When all else fails, let a = 7.  If that doesn't help, then read the manual.
>
>
>


Reply | Threaded
Open this post in threaded view
|

re: The Dilemma: Building a Futuristic GUI for Ephestos

ccrraaiigg
In reply to this post by Eliot Miranda-2

> [Ffenestri] does not constitute a replacement for the current window
> system though does it? But Vassili's work can be.

     Of course. Until a couple of hours ago, though, I didn't know it
existed.

> We had it in production at customer sites.  We could use it for
> development.  It was complete, in the sense that one could open
> arbitrary system windows as native windows, switch them back to
> "virtual" windows, snapshot etc and everything would keep working.
> That's "working".  With great respect to Tim and John, their work in
> Ffenestri is not the same thing, is it?

     Of course not. :)  Whoa, you seem to be under the impression I'm
advocating for Ffenestri here in 2014. I'm not; I only wanted some
detail as to why it's no longer interesting.

> Being critical is not being insulting.  It's merely being objective.
> At least I hope I'm being objective and not insulting anyone.  It is
> not my intent.

     Yikes, I never thought you got anywhere near insulting anyone. Yes,
criticism is essential, that's why I asked to hear some. :)


     thanks again,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: The Dilemma: Building a Futuristic GUI for Ephestos

timrowledge
In reply to this post by Eliot Miranda-2

On 15-09-2014, at 2:11 PM, Eliot Miranda <[hidden email]> wrote:

>   With great respect to Tim and John, their work in Ffenestri is not the same thing, is it?  By the same criteria I don't think what Qwaq did constituted a real system; it allowed the login WIndow to be displayed natively, but it didn't support development tools and it certainly didn't support snapshot or dynamic switching.  Being critical is not being insulting.  It's merely being objective.  At least I hope I'm being objective and not insulting anyone.  It is not my intent.

Not insulting at all. As I said, John & I did the most basic low-level stuff in preparation for more advanced work by other people (for general use) and ourselves (for Sophie). We didn’t get to ever go back to it for Sophie (which foundered on the all too common altar of “it must be rewritten in java” and died) and despite the claims about how important the host window thing was nobody took it up.

It will be interesting to see if anyone will be able to do anything with Vassili’s work.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Found missing



Reply | Threaded
Open this post in threaded view
|

re: The Dilemma: Building a Futuristic GUI for Ephestos

ccrraaiigg

> It will be interesting to see if anyone will be able to do anything
> with Vassili’s work.

     And whether, after Anyone does, Someone will acknowledge that
simple fact. This stuff matters.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: The Dilemma: Building a Futuristic GUI for Ephestos

Bert Freudenberg
In reply to this post by timrowledge
On 15.09.2014, at 22:47, tim Rowledge <[hidden email]> wrote:

> On 15-09-2014, at 1:40 PM, Craig Latta <[hidden email]> wrote:
>
>>> I don't think anybody ever even reported trying [Ffenestri].
>>
>>   I did; it worked. And I just said so again a few messages ago. Hm.
>
> Well ok, but you’re hardly ‘anybody’. :-)

And me neither? I made it work again not so long ago.

        DisplayHostWindow examplePaint inspect

even did survive an image save/restart.

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Chris Muller-3
In reply to this post by Eliot Miranda-2
On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo
<[hidden email]> wrote:

> 2014-09-16 14:37 GMT-03:00 Sebastian Sastre <[hidden email]>:
>
>> Well, a while ago in the business list I’ve raised the idea that making
>> Pharo able to do native OS windows would help it to gain market space (as in
>> the opposite of staying at the margins of it).
>>
>> So, I’d be very positively curious about being able to use Pharo to do
>> multiplatform native apps
>
> The trend is shifting to mobile devices, iOS and Android are eating
> the whole market. So if it is about the potential market size, native
> mobile (tablets/phones/TVs) should come as the first option, before
> desktop.

+1.  Desktop apps are "dead" aren't they?  I'm doubtful that native
windows would help Smalltalk's popularity, as evidenced, I guess, by
the fact VA and VW have supported them for a long time; did they take
over the world yet?

> For development, native windows could prove very useful.

How so?  For me, one of the worst aspects of trying to develop in
VisualAge or VisualWorks *is* the multiple host windows.  It makes it
virtually impossible to work in more than one image, and reinforces
the "grand cathedral" thinking about Smalltalk; e.g. you're not
supposed to want or need anything outside your one, true, image.
Dinosaur!

I constantly work in multiple images, not only for separate projects
but for the ability to quickly and easily fork images for multicore
processing on the same project.  Other times simply to try something
temporary and possibly dangerous.  The memory isolation is critical
for productivity, the UI isolation for usability, and the multi-core
capability for performance.

I think we should focus on how to move to more and smaller
intercommunicating images rather than one big image.  I understand its
appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware
of any other use-cases where multiple host windows would be preferable
to one host window per image.

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2


On Tue, Sep 16, 2014 at 2:19 PM, Chris Muller <[hidden email]> wrote:
On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo
<[hidden email]> wrote:
> 2014-09-16 14:37 GMT-03:00 Sebastian Sastre <[hidden email]>:
>
>> Well, a while ago in the business list I’ve raised the idea that making
>> Pharo able to do native OS windows would help it to gain market space (as in
>> the opposite of staying at the margins of it).
>>
>> So, I’d be very positively curious about being able to use Pharo to do
>> multiplatform native apps
>
> The trend is shifting to mobile devices, iOS and Android are eating
> the whole market. So if it is about the potential market size, native
> mobile (tablets/phones/TVs) should come as the first option, before
> desktop.

+1.  Desktop apps are "dead" aren't they?  I'm doubtful that native
windows would help Smalltalk's popularity, as evidenced, I guess, by
the fact VA and VW have supported them for a long time; did they take
over the world yet?

> For development, native windows could prove very useful.

How so?  For me, one of the worst aspects of trying to develop in
VisualAge or VisualWorks *is* the multiple host windows.  It makes it
virtually impossible to work in more than one image, and reinforces
the "grand cathedral" thinking about Smalltalk; e.g. you're not
supposed to want or need anything outside your one, true, image.
Dinosaur!

I constantly work in multiple images, not only for separate projects
but for the ability to quickly and easily fork images for multicore
processing on the same project.  Other times simply to try something
temporary and possibly dangerous.  The memory isolation is critical
for productivity, the UI isolation for usability, and the multi-core
capability for performance.

I think we should focus on how to move to more and smaller
intercommunicating images rather than one big image.  I understand its
appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware
of any other use-cases where multiple host windows would be preferable
to one host window per image.

That all makes sense from an experienced Smalltalker's POV.  But for people exploring the technology the lack of native windows is usually a huge turn-off and often reason to reject the technology.  The nice thing about Vassili's work is that it allows one to have *both*, without losing window state, and one can switch dynamically, and, IIRC, mix both, e.g. for development.  So it isn't an exclusive choice.

Re VisualWorks' support for native windows it was an essential component to VW staying in the market-place.  If it hadn't supported native windows it would have died the commercial death long ago.  Pre-web, one /had/ to have native windows for industry, and now with mobile native look and feel is even more important.  Further, VWs huge lack in its GUI was lack of support for native widgets.  We always used to tout MSWord's use of emulated widgets (apparently for performance reasons) as a defence but it didn't convince. The customer was always provided with poor emulations and a limited supply.  IMO, native widgets would have made a big difference in hwo well-received VW was for GUI applications, where those using Windows could always turn to VSE.

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Chris Muller-4
>> On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo
>> <[hidden email]> wrote:
>> > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre
>> > <[hidden email]>:
>> >
>> >> Well, a while ago in the business list I’ve raised the idea that making
>> >> Pharo able to do native OS windows would help it to gain market space
>> >> (as in
>> >> the opposite of staying at the margins of it).
>> >>
>> >> So, I’d be very positively curious about being able to use Pharo to do
>> >> multiplatform native apps
>> >
>> > The trend is shifting to mobile devices, iOS and Android are eating
>> > the whole market. So if it is about the potential market size, native
>> > mobile (tablets/phones/TVs) should come as the first option, before
>> > desktop.
>>
>> +1.  Desktop apps are "dead" aren't they?  I'm doubtful that native
>> windows would help Smalltalk's popularity, as evidenced, I guess, by
>> the fact VA and VW have supported them for a long time; did they take
>> over the world yet?
>>
>> > For development, native windows could prove very useful.
>>
>> How so?  For me, one of the worst aspects of trying to develop in
>> VisualAge or VisualWorks *is* the multiple host windows.  It makes it
>> virtually impossible to work in more than one image, and reinforces
>> the "grand cathedral" thinking about Smalltalk; e.g. you're not
>> supposed to want or need anything outside your one, true, image.
>> Dinosaur!
>>
>> I constantly work in multiple images, not only for separate projects
>> but for the ability to quickly and easily fork images for multicore
>> processing on the same project.  Other times simply to try something
>> temporary and possibly dangerous.  The memory isolation is critical
>> for productivity, the UI isolation for usability, and the multi-core
>> capability for performance.
>>
>> I think we should focus on how to move to more and smaller
>> intercommunicating images rather than one big image.  I understand its
>> appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware
>> of any other use-cases where multiple host windows would be preferable
>> to one host window per image.
>
>
> That all makes sense from an experienced Smalltalker's POV.  But for people
> exploring the technology the lack of native windows is usually a huge
> turn-off and often reason to reject the technology.  The nice thing about
> Vassili's work is that it allows one to have *both*, without losing window
> state, and one can switch dynamically, and, IIRC, mix both, e.g. for
> development.  So it isn't an exclusive choice.

Ah, good.  Choice is good.  :)

> Re VisualWorks' support for native windows it was an essential component to
> VW staying in the market-place.  If it hadn't supported native windows it
> would have died the commercial death long ago.  Pre-web, one /had/ to have
> native windows for industry, and now with mobile native look and feel is
> even more important.  Further, VWs huge lack in its GUI was lack of support
> for native widgets.  We always used to tout MSWord's use of emulated widgets
> (apparently for performance reasons) as a defence but it didn't convince.
> The customer was always provided with poor emulations and a limited supply.
> IMO, native widgets would have made a big difference in hwo well-received VW
> was for GUI applications, where those using Windows could always turn to
> VSE.

Yes, I don't doubt that at all, especially during the time when
Windows NT / XP was the defacto platform one could expect anywhere and
everywhere.

I am curious now, however, in this technologically-splintered world
where Windows XP dying out, Windows 7 barely hanging on, everybody
hating Windows 8, and the promise of cheap upgrade to Windows 9, Plus
don't forget OSX widgets and then all the "widgets" people use on
their phones and tablets being basically different from app to app:
what IS "native" widgets these days?  I wonder what those manager
folks who shunned the
non-native-but-perfectly-usable-and-in-some-cases-better widgets are
asking for now?   :)

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

Torsten Bergmann
In reply to this post by Eliot Miranda-2
Hi Eliot,

Yes - in the past most Smalltalks did not have native widgets and usually emulated
the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool
to run 1:1 on another machine it would have been to much manpower for the vendor
to reimplement all the nice widgets to really look like the native system. Especially
when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft.
 
Even with good looking widgets/icons one could see from the speed and repainting issues
(white rectangles for damage areas) that Smalltalk was not native. Also native widgets had
other nice features like virtual modes for TreeViews/ListViews used if you want to display
many nodes.

Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially
the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes
there is SWT in Java providing native widgets - but how many applications are based on
it? Only a few.

On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if
you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at
creating powerfull systems but often fail when it comes to UI design and usability. Squeak
was special and flexible with Morphic (even without multiple windows) - but looked too toyish.

So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had
built a UI in Smalltalk it was part of a rich client application and often people compared
it to other native applications or new widgets found in MS Office.

But in the past customer also asked for COM/COM+, CORBA and webservices while today
it is often much easier to exchange data or call functionality via HTTP, REST, ...

So time and expectations have changed a lot meanwhile. Especially for the UI's.
Desktop platforms unite with the web and in the web it is also possible to look more
like platforms or style to look like a native app. See [1] and [2] for two simple examples.

While the browsers and JS engines become faster this will also change more the way
we think about applications: no installation, styleable, clear look. The google
chrome experiments are a good page to see how this will soon look like. And we will
be independent from devices and screen resolution. In fact more and more applications
we use today run on a computers webbrowser, tablet or a smartphone (often the same way).

With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the
UI side. The Canvas element and WebGL will also drive this forward.
Even if one does not like web technologies - it currently is the platform where
you reach people easily.

Smalltalk should/could have a place in this (web centric) world:

  1. As a backend to serve the web
  2. On the client
  3. Combining 1. and 2.

For the first we have Seaside, TeaPot, Aida, ...
For the seond: as it will not happen that browser vendors agree and threw out JavaScript in
favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do.

But we should also rethink Smalltalk to find a better place as a scripting language. What
I still would like to see:

 - tiny and fast VM with a command line and REPL
 - one unified and easy to use FFI with callbacks so one can use the platform, maybe
   others will write the bindings then
 - single small base image but fast loadable binary code components (modules, maybe using the
   LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's
 - but still with the ability to bootstrap up to a full saveable image
 - ability to serve the web with easy callbacks into Smalltalk for implementing functionality
   (especially with this we may catch 90% of the usual UI cases).

Bye
T.

[1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html
[2] jQuery Desktop http://desktop.sonspring.com/
[3] Chrome Experiments http://www.chromeexperiments.com/

tty
Reply | Threaded
Open this post in threaded view
|

Re: Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

tty
What Torsten said.

When I get the darn CMake stuff done, I will be turning to REPL work and multi-core work (assuming I develop the chops to get it done)

Put a factory pattern in place where morphic currently launches and provide a 'seaside' gui rendering engine using the renderContentOn: aCanvas idiom as an option.
Use both for the web and the desktop and let CSS folks design their looks and feels.

my $0.02.

cordially,

tty





---- On Tue, 16 Sep 2014 16:12:05 -0700 Torsten Bergmann <[hidden email]> wrote ----

Hi Eliot,

Yes - in the past most Smalltalks did not have native widgets and usually emulated
the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool
to run 1:1 on another machine it would have been to much manpower for the vendor
to reimplement all the nice widgets to really look like the native system. Especially
when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft.

Even with good looking widgets/icons one could see from the speed and repainting issues
(white rectangles for damage areas) that Smalltalk was not native. Also native widgets had
other nice features like virtual modes for TreeViews/ListViews used if you want to display
many nodes.

Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially
the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes
there is SWT in Java providing native widgets - but how many applications are based on
it? Only a few.

On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if
you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at
creating powerfull systems but often fail when it comes to UI design and usability. Squeak
was special and flexible with Morphic (even without multiple windows) - but looked too toyish.

So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had
built a UI in Smalltalk it was part of a rich client application and often people compared
it to other native applications or new widgets found in MS Office.

But in the past customer also asked for COM/COM+, CORBA and webservices while today
it is often much easier to exchange data or call functionality via HTTP, REST, ...

So time and expectations have changed a lot meanwhile. Especially for the UI's.
Desktop platforms unite with the web and in the web it is also possible to look more
like platforms or style to look like a native app. See [1] and [2] for two simple examples.

While the browsers and JS engines become faster this will also change more the way
we think about applications: no installation, styleable, clear look. The google
chrome experiments are a good page to see how this will soon look like. And we will
be independent from devices and screen resolution. In fact more and more applications
we use today run on a computers webbrowser, tablet or a smartphone (often the same way).

With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the
UI side. The Canvas element and WebGL will also drive this forward.
Even if one does not like web technologies - it currently is the platform where
you reach people easily.

Smalltalk should/could have a place in this (web centric) world:

1. As a backend to serve the web
2. On the client
3. Combining 1. and 2.

For the first we have Seaside, TeaPot, Aida, ...
For the seond: as it will not happen that browser vendors agree and threw out JavaScript in
favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do.

But we should also rethink Smalltalk to find a better place as a scripting language. What
I still would like to see:

- tiny and fast VM with a command line and REPL
- one unified and easy to use FFI with callbacks so one can use the platform, maybe
others will write the bindings then
- single small base image but fast loadable binary code components (modules, maybe using the
LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's
- but still with the ability to bootstrap up to a full saveable image
- ability to serve the web with easy callbacks into Smalltalk for implementing functionality
(especially with this we may catch 90% of the usual UI cases).

Bye
T.

[1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html
[2] jQuery Desktop http://desktop.sonspring.com/
[3] Chrome Experiments http://www.chromeexperiments.com/




Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2
In reply to this post by Chris Muller-4


On Tue, Sep 16, 2014 at 2:55 PM, Chris Muller <[hidden email]> wrote:
>> On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo
>> <[hidden email]> wrote:
>> > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre
>> > <[hidden email]>:
>> >
>> >> Well, a while ago in the business list I’ve raised the idea that making
>> >> Pharo able to do native OS windows would help it to gain market space
>> >> (as in
>> >> the opposite of staying at the margins of it).
>> >>
>> >> So, I’d be very positively curious about being able to use Pharo to do
>> >> multiplatform native apps
>> >
>> > The trend is shifting to mobile devices, iOS and Android are eating
>> > the whole market. So if it is about the potential market size, native
>> > mobile (tablets/phones/TVs) should come as the first option, before
>> > desktop.
>>
>> +1.  Desktop apps are "dead" aren't they?  I'm doubtful that native
>> windows would help Smalltalk's popularity, as evidenced, I guess, by
>> the fact VA and VW have supported them for a long time; did they take
>> over the world yet?
>>
>> > For development, native windows could prove very useful.
>>
>> How so?  For me, one of the worst aspects of trying to develop in
>> VisualAge or VisualWorks *is* the multiple host windows.  It makes it
>> virtually impossible to work in more than one image, and reinforces
>> the "grand cathedral" thinking about Smalltalk; e.g. you're not
>> supposed to want or need anything outside your one, true, image.
>> Dinosaur!
>>
>> I constantly work in multiple images, not only for separate projects
>> but for the ability to quickly and easily fork images for multicore
>> processing on the same project.  Other times simply to try something
>> temporary and possibly dangerous.  The memory isolation is critical
>> for productivity, the UI isolation for usability, and the multi-core
>> capability for performance.
>>
>> I think we should focus on how to move to more and smaller
>> intercommunicating images rather than one big image.  I understand its
>> appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware
>> of any other use-cases where multiple host windows would be preferable
>> to one host window per image.
>
>
> That all makes sense from an experienced Smalltalker's POV.  But for people
> exploring the technology the lack of native windows is usually a huge
> turn-off and often reason to reject the technology.  The nice thing about
> Vassili's work is that it allows one to have *both*, without losing window
> state, and one can switch dynamically, and, IIRC, mix both, e.g. for
> development.  So it isn't an exclusive choice.

Ah, good.  Choice is good.  :)

> Re VisualWorks' support for native windows it was an essential component to
> VW staying in the market-place.  If it hadn't supported native windows it
> would have died the commercial death long ago.  Pre-web, one /had/ to have
> native windows for industry, and now with mobile native look and feel is
> even more important.  Further, VWs huge lack in its GUI was lack of support
> for native widgets.  We always used to tout MSWord's use of emulated widgets
> (apparently for performance reasons) as a defence but it didn't convince.
> The customer was always provided with poor emulations and a limited supply.
> IMO, native widgets would have made a big difference in hwo well-received VW
> was for GUI applications, where those using Windows could always turn to
> VSE.

Yes, I don't doubt that at all, especially during the time when
Windows NT / XP was the defacto platform one could expect anywhere and
everywhere.

I am curious now, however, in this technologically-splintered world
where Windows XP dying out, Windows 7 barely hanging on, everybody
hating Windows 8, and the promise of cheap upgrade to Windows 9, Plus
don't forget OSX widgets and then all the "widgets" people use on
their phones and tablets being basically different from app to app:
what IS "native" widgets these days? 

Native widgets means simply use of the platforms native widget set in constructing user interfaces.  I don't dsee different widgets across iOS devices.  I see lots of consistency.
 
I wonder what those manager
folks who shunned the
non-native-but-perfectly-usable-and-in-some-cases-better widgets are
asking for now?   :)

I assume good looking applications using native widgets in the host look-and-feel that follow the platform's style and usability guidelines.  Thats a reasonable request.  Look at how coherent and well-engineered the interface components in something like Apple's iOS is are and one soon realises one the one hand the interface quality is high and on the other that the only feasible way to construct interactive applications in that context is to build it out of those widgets, not emulate, not provide an alternative.  There are exceptions, e.g. parts of games where all one needs is touch events and all imagery is custom.  But for stereotypical interaction one surely has to use native widgets.

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2
In reply to this post by Torsten Bergmann
Hi Torsten,

On Tue, Sep 16, 2014 at 4:12 PM, Torsten Bergmann <[hidden email]> wrote:
Hi Eliot,

Yes - in the past most Smalltalks did not have native widgets and usually emulated
the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool
to run 1:1 on another machine it would have been to much manpower for the vendor
to reimplement all the nice widgets to really look like the native system. Especially
when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft.

Even with good looking widgets/icons one could see from the speed and repainting issues
(white rectangles for damage areas) that Smalltalk was not native. Also native widgets had
other nice features like virtual modes for TreeViews/ListViews used if you want to display
many nodes.

Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially
the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes
there is SWT in Java providing native widgets - but how many applications are based on
it? Only a few.

On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if
you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at
creating powerfull systems but often fail when it comes to UI design and usability. Squeak
was special and flexible with Morphic (even without multiple windows) - but looked too toyish.

So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had
built a UI in Smalltalk it was part of a rich client application and often people compared
it to other native applications or new widgets found in MS Office.

That's a great summary. +1.
 
But in the past customer also asked for COM/COM+, CORBA and webservices while today
it is often much easier to exchange data or call functionality via HTTP, REST, ...

Sure, but that's invisible glue; not the same as UI components for the user.  So there's a bit of a non-sequitur extrapolating from UI (user to system) to system to system connectivity.
 
So time and expectations have changed a lot meanwhile. Especially for the UI's.
Desktop platforms unite with the web and in the web it is also possible to look more
like platforms or style to look like a native app. See [1] and [2] for two simple examples.

While the browsers and JS engines become faster this will also change more the way
we think about applications: no installation, styleable, clear look. The google
chrome experiments are a good page to see how this will soon look like. And we will
be independent from devices and screen resolution. In fact more and more applications
we use today run on a computers webbrowser, tablet or a smartphone (often the same way).

With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the
UI side. The Canvas element and WebGL will also drive this forward.
Even if one does not like web technologies - it currently is the platform where
you reach people easily.

Smalltalk should/could have a place in this (web centric) world:

  1. As a backend to serve the web
  2. On the client
  3. Combining 1. and 2.

For the first we have Seaside, TeaPot, Aida, ...
For the seond: as it will not happen that browser vendors agree and threw out JavaScript in
favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do.

But we should also rethink Smalltalk to find a better place as a scripting language. What
I still would like to see:

 - tiny and fast VM with a command line and REPL

We're getting there with fast.  Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is 453k, 386k code, 68k data.  That includes the interpreter, JIT, core primitives and memory manager/GC. Add on several k for the FFI, C library et al and a VM in a megabyte is realistic.  Is that in the right ball park?

 - one unified and easy to use FFI with callbacks so one can use the platform, maybe
   others will write the bindings then

+1.  Again that's central to our efforts.
 
 - single small base image but fast loadable binary code components (modules, maybe using the
   LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's

Yep.  But personally I think Fuel is better and just as fast.  Certainly that's the parcels experience.
 
 - but still with the ability to bootstrap up to a full saveable image

+1.
 
 - ability to serve the web with easy callbacks into Smalltalk for implementing functionality
   (especially with this we may catch 90% of the usual UI cases).

This we'll leave to the web framework designers, but it seems eminently doable no?
 

Bye
T.

[1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html
[2] jQuery Desktop http://desktop.sonspring.com/
[3] Chrome Experiments http://www.chromeexperiments.com/

I love the circle game but oh boy does the implementation show through in the pauses.  My old 5.x Safari pauses noticeably every two seconds or so. Chrome is smooth.

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

Eliot Miranda-2
Hi Torsten,

    wow, what a great summary.  Thanks.  See below.

On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann <[hidden email]> wrote:
Eliot wrote:
>We're getting there with fast.  Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data.  That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic.  Is that in the right ball park?

Yes, wet's my appetite :)

Tiny means easy to download and use for scripting, no other dependencies
for the out of the box REPL experience. But still powerfull to built one on another
and scale up to large programs.

Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple
things like:

   c:\myscripts\ts.exe -e 3+4
   7

where ts.exe is the VM in a few kB including a small initial kernel image (as part of
the PE DATA section). It should be able to run scripts:

   c:\myscripst\ts.exe automate.st

It should be possible to easily build components (either with or without the sources):

   ts.exe sunit.st -o sunit.sll
   ts.exe sunit.st -noSource -o sunit.sll

So you can either include other scripts

   ts.exe -i sunit.st  mytests.st

or link the previously built binary components to form something new.

   ts.exe -l junit.sll mytests.st

But it should be possible to build another vm+image easily:

      ts.exe -i mykillerapp.st  -o killerapp.exe
 or   ts.exe -l mykillerapp.sll -o killerapp.exe

by writing a new PE file for Windows either including a new kernel image or a combined
one based on the already built-in initial kernel of the previous one.
So I can deploy a killerapp or reassemble it to form the next language version.

SmallScript was very close to that and it was a nice thing to work with.
Especially since usually Smalltalk usually throws things out at the end - but
one never builds a house by carving it out of a rock. We need bricks to assemble.

+1000.

With the above scheme you could build components, some of them portable, others
explicitly non-portable as the code includes native calls. The later have to
be rebuilt on the other platform - so if you have good design abstractions you
can implement a UI lib on Windows and one on Mac.

Some of the components are with the source code packaged in for debugging
(but not changeable), for closed source components you leave it out.

And still it should support pinnable objects (not moved by GC for callouts),
sandboxing, Classes with UUIDs to allow for side by side loading/migration
and an extensible meta-scheme as this is where Smalltalk is still the hero of all
und metaprogramming will be our future.

So so far I have pinning.  But I'd love to hear more detail on sandboxing.  I'm not sure about UUIDs.  What about other mechanisms, namespaces, ClassBoxes?  UUID sounds too much like an implementation to me.  No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????).  How about reitierating this more abstractly?


Also the VM should be available as a shared component - so it can run in-process
in other programs like a web browser. Always wished to write:

   <script type="text/tinyscript">
         BrowserLog write: 'HelloWorld'.
   </script>

directly in HTML.

And this is only the beginning of the wish list...

Please, I'd love to have you write a fuller list.  We could add it to the list at Cog Projects or add it to a "Directions" page or some such.  But capturing these ideas is importasnt.

>Yep.  But personally I think Fuel is better and just as fast.  Certainly that's the parcels experience.
>  - but still with the ability to bootstrap up to a full saveable image

Yes, Fuel would be an option. At least it would be platform independent. Not sure
about other options (quick loading by mapping component using memory mapped files etc.)

Well, mapping finished images a la VW's PermSpace is probably easier.  The memory mapping in .Nt is extremely complex.  But I get the requirement; ultra-fast start-up of small components.
 
>This we'll leave to the web framework designers, but it seems eminently doable no?

For sure.

Bye
Torsten

thanks again.  And give serious thought to carefully enunciating these requirements/this design sketch? 

--
best,
Eliot


12