The Dilemma: Building a Futuristic GUI for Ephestos
Locked
1234
1234
Re: The Dilemma: Building a Futuristic GUI for Ephestos
 
|
Le 14/09/2014 18:20, kilon alios a écrit :
> 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. > I understand your frustration because I felt it a few months ago. Now, you should bet on Athens, that the less risky way and it is part of Pharo itself, and it is backed by a C library. For DrGeo, I found bitmap rendering to be much faster after Athens use. Whenever you meet issue, Igor will be helpful and this will help improving Athens. Now, I have to admit I don't understand why Igor was distracted with other task before finishing and polishing the Athens support on the image. It brings to destabilizing state for newcomer or even expert willing to invest on Athens use. I got lost many time and I was close to throw all the code through the window as well. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
hehe you have not seen me frustrated if you not have seen me code in C++ for windows and being so frustrated at Microsoft MFC that I punched my screen :D That was 20 years ago and fortunately I have not punched a screen since then. That day was the day I realised I did not have the patience , the metal, to become a professional coder. Coding in Pharo was the most fun I have ever had coding in any programming language. Nah I only have love for Pharo, this is why each time I contributed I did not even have a doubt. I think Pharo is awesome and deserves to be 1.000.000 times more popular. The problems I described is a natural thing for unpopular software. Its not the fault of Pharo its not anyone's fault. Actually I feel Pharo is on the right road, even on the documentation front that I always complained Pharo for the Enterprise is very active and new content is added almost daily. So Pharo is 100% on the right road to success. My problem is not Igor , or Athens or transparency animation with pngs. The problem is that Blender is way more powerful and tailor made for my needs, Pharo is not. I knew that before starting with Pharo and I knew that Pharo would something to have fun thing for some time. Blender is 1 million lines of code , speciallised to high performance 3d graphics , build on top of a language that is the most popular for 3d graphics and on top of very powerful and mature libraries for 3d. So Pharo was never trully want I wanted and I knew that. Pharo was the most beautiful distraction. I just realised it was about time to get coding Blender source. I played around with Pharo so much cause I was not eager to start coding again in C++ :D Also I think its unfair to put Athens in one developer responsibility, there is only so much one coder can do and frankly Igor has already done a lot for Pharo. Athens is certainly not the only area Pharo needs polishing. Lets talk about very basic stuff like git support , Pharo is not there yet. If you have worked with other languages there are some things that you take for granted. Igor has been more than helpful, never left any of my questions about Athens and NBOpenGL unanswered , he is a great guy :) So I have only love for Pharo I will keep playing around with it , just way less frequently. I wish you all good luck, thanks for helping me understand and enjoy Pharo. See you around :) On Sun, Sep 14, 2014 at 10:07 PM, Hilaire <[hidden email]> wrote: Le 14/09/2014 18:20, kilon alios a écrit : |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
In reply to this post by kilon.alios
On 14 September 2014 18:54, kilon alios <[hidden email]> wrote:
There is a saying that if you want something done, right you've got to do it yourself, and this means working harder at it. Stuff like that get's easier with the passage of time, but time is what you don't seem to have and you may not have enough collaborators in your project. Seeing as you mentioned Delphi, you might consider the FreePascal/Lazarus combination and consider building a Smalltalk on top if it as you need a combination which gives the ease of an interpreter and live coding, together with the facility to get down to the metal when you need it. It also has the benefit of being crossplatform. C++ is really an insane language to attempt to do something like that in. The newer languages like Nimrod and Julia may be better, but they don't have the rich library set you need. I've always felt that the design of Smalltalk/X offers a better foundation for the type of stuff you want to accomplish so long as you are willing to meet the conditions for using it for defense related and biotech purposes. You will find the going tough as even Jan Vrany is not working on it much. All in all I would say Smalltalk is the right language for what you want to do, it is just that the free versions available don't match your exact needs, both in terms of libraries and level of mass adoption. Frank Church ======================= http://devblog.brahmancreations.com |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
I don't plan to do anything complicated with C++ just contribute bug fixes to blender and maybe add a few features here and there. Definetly not implementing a Smalltalk into it :D I am also interesting in improving my mathematical knowledge about 3d graphics. I am foremost a 3d artist, but I like the idea of customising my own tools. I would not design anything from scratch since there are already tons of open source projects. Designing my own Smalltalk is out of the question, I prefer small projects easy to do and realistic / practical. Yeap I am aware of FP and Lazarus , I may play around them too but I will be facing the same problem I face with Pharo since they are not much popular either and has nothing that can compete with Blender for 3d graphics. I am not interested in commrecial Smalltalks from what I have seen Pharo looks better, maybe they have bigger libraries a bit more docs, but I dont think it would make much of a difference. If you are serious about coding 3d and 2d graphics , in the end knowning C/C++ is a big plus since most of development happens in those languages. I never said Smalltalk or Pharo is the wrong language for what I want to do , it was always a matter of tools and libraries. I may do something crazy like create a parser from Pharo to C++ , I think that would be interesting and would allow me to use Pharo for coding Blender source. Not a complete parser just something simple that can turn basic pharo syntax to C++ syntax. I would definitely being interested in something like this. I think Slang already does that so I may look at it and do maybe a few modifications here and there . I wonder if there are other parsers for Pharo to C++ , maybe a pettitparser template ? I would love to keep using Pharo syntax and the IDE and even keep contributing to it if it could generate C++ code. Actually thank you for reminding me about Slang :) On Mon, Sep 15, 2014 at 12:11 AM, vfclists . <[hidden email]> wrote:
|
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
FWIW, Blender has its own UI toolkit. So, they designed their own thing. http://3dicc.com/ 's Terf runs on Cog + internal additions. I guess it shows that things can be done nicely when it comes to UIs. As for Java and UI toolkits, I've been programming in Swing very extensively at one point. Well, as always, when you get into something very specific, you dig into the code and see that the designers of Swing also ran into issues and under the cover, things aren't so neat and debugging event bubbling in these things (where then, there is suddenly *zero* doc) is much harder with Java than with Pharo. UI is always a can of worms. Look at all the moves from Microsoft with WinForms, Silverlight, WPF, ModernUI, and what else... I've done tons of Java and Java EE. Heck, I paid my bills for years doing that, including teaching other people on how to use it properly. Know what? I am now sick of Java. When can we focus on the real problem and not all of the scaffholding? Java is okay, Java has lots of APIs, Java covers a lot of ground. But I just can't stand its ways of writing 20x more code than needed. Pharo is fresh air. One can actually understand what's going on and not merely call APIs around without understanding what's going on inside. Is it frustrating at time, hell yes. But do I end up with better skill after that? You bet! And as for C and C++ for 3D graphics, coders do use premade engines these days, like Unreal, OGRE, or, Urho3D http://urho3d.github.io/about.html. That last one you can script (http://urho3d.github.io/documentation/HEAD/_scripting.html). Whatever the choice or the path, it seems that massive work is needed to get something that works semi-decently out of the door. There is no silver bullet... I wish you find what you are looking for. All the best, Phil On Sun, Sep 14, 2014 at 11:29 PM, kilon alios <[hidden email]> wrote:
|
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
Blender indeed has its own GUI called "Ghost API" which is OpenGL 1 based in order to work even with very old GPUs. I also agree there is no such thing as silver bullet. It also depends on what you want. For example I could port Blender source base as a library to pharo with NB bindings but that would be a massive amount of work and not the same as just making small contributions to Blender. I think in the end, whether you like a programming language or not you have to be realistic about your goals and what you ask from the language. I tried to fit Pharo into my workflow but just it does not fit. The good news is that at least I will be avoiding C++ for now as the part I am most interested in Blender, sculpting is coded in C. But I dont give up on pharo just yet completely, I just said it wont be anymore my main platform. I see no reason why I should not contribute a few bug fixes or enhancements to pharo per year. I would also like to finish porting the 5th chapter of PBE to Pharo 3 at some point. So no worries I will be around, just much less active :) And will definetly follow the mailing list with great interest :) On Mon, Sep 15, 2014 at 2:24 AM, [hidden email] <[hidden email]> wrote:
|
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
In reply to this post by kilon.alios
Le 14/09/2014 21:41, kilon alios a écrit :
> > My problem is not Igor , or Athens or transparency animation with pngs. > The problem is that Blender is way more powerful and tailor made for my > needs, Pharo is not. I knew that before starting with Pharo and I knew > that Pharo would something to have fun thing for some time. Blender is 1 > million lines of code , speciallised to high performance 3d graphics , > build on top of a language that is the most popular for 3d graphics and > on top of very powerful and mature libraries for 3d. > Euh, don't get me wrong, I have nothing to complain against Igor, as I wrote he's very helpful, talented guy with a good load of wisdom. Nevertheless, part of Athens need to be polished and from my pov it looks like it is not the priority, and I am disappointed by that. But again my vision of the situation is from outside, so definitely biased. Regarding Blender and Pharo: don't you want to control Blender engine from a Pharo model. I mean why do you want to bother with graphics and animation rendered by Pharo, it is not what Pharo is good at. What I will do is design the model in Pharo then drive Blender from it. That should be eaiser and benefit from the two worlds. Am I wrong? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
It depends what you mean by control blender. Blender is 2 things a) C/C++ source code that implements all features that users use b) the Python API that allows to use all features that a user can use. Ephestos already allows full access to (b) . So for example if you wanted Dr Geo to export its data to blender so Dr Geo can convert its geometry to 3D and use all the nice features of blender you can do that already with ephestos. But for modifying existing functionality you need to get your hands dirty with the source. Implementing new fuctionality like importers / exporters etc is also doable via API so its doable via Ephestos. But cpu intense new fuctionality is done by modifying the source. I am not excluding creating a parser for the blender source , at first the thought did not cross my mind. If pettitparser has already a C or C++ parser that will be doable for me. I will have to research it further. If its easy enough I may be sticking with Pharo afterall. Le 14/09/2014 21:41, kilon alios a écrit :
Euh, don't get me wrong, I have nothing to complain against Igor, as I wrote he's very helpful, talented guy with a good load of wisdom. Nevertheless, part of Athens need to be polished and from my pov it looks like it is not the priority, and I am disappointed by that. But again my vision of the situation is from outside, so definitely biased. Regarding Blender and Pharo: don't you want to control Blender engine from a Pharo model. I mean why do you want to bother with graphics and animation rendered by Pharo, it is not what Pharo is good at. What I will do is design the model in Pharo then drive Blender from it. That should be eaiser and benefit from the two worlds. Am I wrong? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
May be I wrongly expressed: imagine a 3D game whose model world is in
Pharo then rendered in Blender (I guess model data need to be share between Pahro and Blender, but graphic only reside on Blender). Now you could use the Pharo dev tools like inspector & al. to play with your games. With DrGeo analogy: it will be more like a shared 3D model between Pharo and Blender, and controlled from Pharo. Le 15/09/2014 11:02, kilon alios a écrit : > It depends what you mean by control blender. Blender is 2 things a) > C/C++ source code that implements all features that users use b) the > Python API that allows to use all features that a user can use. Ephestos > already allows full access to (b) . So for example if you wanted Dr Geo > to export its data to blender so Dr Geo can convert its geometry to 3D > and use all the nice features of blender you can do that already with > ephestos. But for modifying existing functionality you need to get your > hands dirty with the source. Implementing new fuctionality like > importers / exporters etc is also doable via API so its doable via > Ephestos. But cpu intense new fuctionality is done by modifying the source. > -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
Yeap you can do that with Ephestos, or you will be able to do it shortly. You can send data from pharo to blender but you cannot send data from blender to pharo. But thats is just a matter of adding a small of piece of code in python side so I will implement it probably today. So yes I hope this week if not today pharo inspector to be able to inspect blender data. I am not sure about the updating though, inspector update its display when the data changes to display the latest data , that would require to keep sending messages to blender to fetch the latest data, its not hard at all just that inspector will have to be modified to do that.I am not familiar with inspector internal so that is up to pharoers to do. So you can now change any model data inside Blender , not just geometry data but anything like textures, materials, animation data and tons more. The Python API has the same access to data structures that the Blender source has so in that department Ephestos is extremely powerful. I have not hooked Ephestos to the Blender Game Engine yet, again that should not be more than an afternoon of work, so I will do it eventually. It may not even needs a change , most likely it wont , just a case of importing a python module. Shared 3d model ? sure that is also doable, when I add to Ephestos the ability to retrieve data from blender you will be able to create your own 3d model, your own pharo objects to wrap blender python objects. Generally you will be able to do anything you can do with Blender from Pharo. The only limitation is not expect the socket used by Ephestos to able to retrieve GBs or even MBs of Blender data in an instant, usually the kind of data that is that big is only the geometry data itself that can be millions of polygons. This is where a FFI solution would be better than my solution using sockets. But then would you want to play with GBs of data in pharo ? I think not. Be warned that Ephestos maps 1 by 1 to the Blender API , that means you have to learn the Blender API and if I implement support for Blender Game Engine then you will need to know the Blender Game Engine API if you want to create a game or a realtime interactive 2d or 3d demo of some sort. Some knowledge , just the basic stuff , of python is desirable too. The only difference is that instead of coding in python you code in pharo. Ephestos has access to all python libraries, and by everything I mean everything . So if you dont want to use the BGE you can use another game engine as long it supports cpython. Unity can work with ironpython from what I read, Ephestos may not work out of the box in that case but with minor modifications it should not be more than a hour of work to get Unity working with Pharo. Again I leave that to anyone that is seriously interested. Ephestos is super simple, very basic socket code, so its easy to port around. The only tricky part is how I parse Pharo syntax to python syntax using regex but I think the code is clear enough to be understood by any experienced pharo coder. Probably it can be improve in many diffirent ways too. The syntax parser however is limited to basic python syntax, like accessing objects , global variables and calling methods and functions. For more advanced stuff like defining python classes, functions, list comprehensions etc you will need to use python syntax inlined inside your Pharo code which Ephestos also offers as fallback. The parser could be expanded to more advanced python syntax I may improve that area in the future. But then I dont I have a problem writing some code in python from pharo. But as I said, the challenge is not using Ephestos but learning Blender and its API which both have a steep learning curve because they offer a ton of functionality. But then the same problem you will face using any of the very powerful Game engines out there. On Mon, Sep 15, 2014 at 12:30 PM, Hilaire <[hidden email]> wrote: May be I wrongly expressed: imagine a 3D game whose model world is in Pharo then rendered in Blender (I guess model data need to be share between Pahro and Blender, but graphic only reside on Blender). Now you could use the Pharo dev tools like inspector & al. to play with your games. |
|
|
In reply to this post by kilon.alios
kilon alios wrote:
You demonstrated your willingness to contribute and I think that goes a long way to balance any number of questions. Now you should appreciate that asking questions actually shows someone making use of a library, which can be good thing for a developer. And as ESR says [1], "The first thing to understand is that hackers actually like hard problems and good, thought-provoking questions about them. [...] If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise." [1] http://www.catb.org/esr/faqs/smart-questions.html (yes I know, my favourite again)
I can definitely understand with your main interest being an existing application like Blender written in C, then developing in C may give you the greatest power. Good luck with it!
I have really appreciated your enthusiasm, your joy of Pharo, and your honest constructive criticisms. Sometimes it can be suspect that Smalltalker fanbois are blinded by their world view, but as a newcomer to Pharo your positive comparisons of Pharo versus languages-you-knew-better were a nice validation of Pharo, even if there remain things to improve. Now life is a long and winding road, so maybe opportunity will arise sometime for you to use Pharo again. I hope you have fun in the meantime! btw, just a parting thought that I had regarding your requirement. Rather than trying to do your Blender graphics rendering on top of some layer in Pharo, you might** use OSWindow [2] to create a native-window-canvas that you pass to Blender for it to render directly into. As I understand it, you could then build a Pharo base GUI around that window. Now if that happened to be possible, your dive into programming Blender in "C" would probably be of great benefit. Maybe something to come back to later. **Disclaimer, I haven't used OSWindow. Its just an intuitive thought. [2] http://smalltalkhub.com/#!/~OS/OS-Windows (scroll down to "The Windows User Interface" and "Graphics") cheers -ben |
|
|
In reply to this post by Nicolai Hess
Yes this is that one. Stef |
|
|
In reply to this post by Nicolai Hess
Guys
the animation of roassal2 are done really simply using viva. Stef On 14/9/14 19:07, Nicolai Hess wrote:
|
|
|
In reply to this post by HilaireFernandes
> I understand your frustration because I felt it a few months ago. > > Now, you should bet on Athens, that the less risky way and it is part > of Pharo itself, and it is backed by a C library. For DrGeo, I found > bitmap rendering to be much faster after Athens use. > Whenever you meet issue, Igor will be helpful and this will help > improving Athens. > > Now, I have to admit I don't understand why Igor was distracted with > other task before finishing and polishing the Athens support on the image. - And igor is working on TxText: writing a texteditor is something that takes time. We need it because we want to display text with athens. - worked on OSWindow We will push it in the image as soon as we release the new integration tool that will manage configurations (like that we can update Zinc, TxText, OSWindow, Athens,.... using configuration) > It brings to destabilizing state for newcomer or even expert willing > to invest on Athens use. I got lost many time and I was close to throw > all the code through the window as well. > > Hilaire > |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
In reply to this post by Ben Coman
thanks for you kind words Ben. No the GUI I am developing for Ephestos is suppose to be separate from Blender , I have no intention of forking Blender and maintaining such fork. Regarding OSWindow that wont be necessary I will most likely use Ephestos to access pyQT which in turn will give me access to QT. So most likely I will be building the futuristic GUI on top of QT. I could also bypass python and do a C++ wrapper for pharo for QT, not full functionality but rather the parts that interest me but that will be a lot more tricky. I have changed my mind, with the advice I have been getting here and in the parser C++ thread it looks like I will keep using pharo for generation of my C code. Afterall Slang is already heavily used so I think I can rely on it. What Slang cannot do I can do it coding manually in C. So I think I can fit Pharo to my workflow quite a lot. Very happy to be proven once more wrong about Pharo :) On Mon, Sep 15, 2014 at 4:21 PM, Ben Coman <[hidden email]> wrote:
|
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
In reply to this post by Nicolai Hess
On Sun, Sep 14, 2014 at 10:07 AM, Nicolai Hess <[hidden email]> wrote:
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).
best, Eliot
|
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
> ...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. thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
On Mon, Sep 15, 2014 at 12:31 PM, Craig Latta <[hidden email]> wrote:
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, best, Eliot
|
Re: [squeak-dev] re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
Hi Craig,
On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <[hidden email]> wrote: --
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
|
Re: [squeak-dev] re: The Dilemma: Building a Futuristic GUI for Ephestos
|
|
The problem with relying for everything on smalltalk code and not using existing technology is two fold a) You cannot compete with existing solution, they come with more manpower , have more features, better documention, more bug fixes, more, more ...... more b) One day the authors of the library decide to give up on the library because they went off to other things and of course it falls to the shoulders of others that are much less motivated and have other things in their plate too with higher priority for them. The library continues to improve but at a glacial pace. Its perfectly ok to try your own things and follow your own road. Everyone loves to experiment and do things his own way and that has many positive. But the general refusal to embrace existing technologies even problematic ones make the job of spreading the Smalltalk appeal much harder. Makes it harder for people to transition from other languages too. This smalltalk mentality is wrong. The end. On Tue, Sep 16, 2014 at 12:11 AM, Eliot Miranda <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |