Spec Understandability
Locked
 
Administrator
|
What is one supposed to do with an error like this? It's about as readable as a C++ template error ;)
PanelMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each | self class private_interpretASpec: each ...etc... Array(SequenceableCollection)>>collect: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter>>computeSpecFrom:selector: SpecInterpreter>>retrieveSpecFrom:selector: SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each | self class private_interpretASpec: each ...etc... Array(SequenceableCollection)>>collect: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter class>>private_buildWidgetFor:withSpec: (ComposableModel)>>private_buildWithSpec: (ComposableModel)>>private_buildWithSpec SpecInterpreter>>returnInterpretationOf: SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector:
Cheers,
Sean |
|
Administrator
|
It seems like you can no longer do: "self instantiate: MyComposableModelSubclass" What is the appropriate migration?
Cheers,
Sean |
|
Administrator
|
Oops, nevermind. It was: "PanelMorph" -> "PanelMorph asSpecAdapter"
Cheers,
Sean |
|
Administrator
|
In reply to this post by Sean P. DeNigris
Besides error intractability, there is also a cost to understanding the system via exploration - a glorious benefit of Morphic. In the past, one only had to bring up halos on and inspect a button to see how to duplicate its action. Now, to see what happens when one presses Versionner's "Commit the project" button, you have to drill down in the inspector from aButtonXyzMorph -> model -> actionHolder -> value, a tedious and opaque process. Of course, I'm not in any way against Spec or its goals, just sharing my unfolding experience using it.
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
> Besides error intractability, there is also a cost to understanding the I'm running Squeak 4.0 but I assume my question still applies. If not, other> system via exploration - a glorious benefit of Morphic. In the past, one > only had to bring up halos on and inspect a button to see how to duplicate > its action. Now, to see what happens when one presses Versionner's "Commit > the project" button, you have to drill down in the inspector from > aButtonXyzMorph -> model -> actionHolder -> value, a tedious and opaque > process. > Of course, I'm not in any way against Spec or its goals, just sharing my > unfolding experience using it. implies they are quite useful. > its action" mean? Could you please describe in step by step detail. |
|
|
Hi Ralph,
On Mon, Oct 20, 2014 at 9:08 AM, Ralph Boland <[hidden email]> wrote: --
I would upgrade to 4.5 asap. That's ancient. Are you still using the interpreter VM? If so, you can change to the JIT. It's a lot faster. And to the Spur VM which is faster still.
Right click on any window. Then grab the Swirl halo (dark blue) and tug it. Quite useful I'd say ;-)  The rotation halo might be only for fun, but many of the others are really useful, allowing you to move, delete, inspect, take an image, copy, etc, etc, etc. best, Eliot
|
|
Administrator
|
In reply to this post by Ralph Boland
Hi Ralph! I think the best way to understand why Morphic is revolutionary is to read the papers of its creators (e.g. http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLivenessInMorphic.pdf). I also wrote http://stackoverflow.com/a/4410189/424245 which should give a taste and also answers your question more directly. HTH.
Cheers,
Sean |
|
|
Note that halo implementation sucks!
In Bloc alain clean it and he is able to plug halos and package them cleanly. In addition in Bloc he took the decision not to implement for now the direct creation of certain widget because this kind of feature leads to spaghetti dependencies. Stef On 20/10/14 20:35, Sean P. DeNigris wrote: > Ralph Boland wrote >> I am not in the habit of using halos, not really sure what they are for. >> But your description implies they are quite useful. >> What does "bring up halos on and inspect a button to see how to duplicate >> its action" mean? Could you please describe in step by step detail. > Hi Ralph! I think the best way to understand why Morphic is revolutionary is > to read the papers of its creators (e.g. > http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLivenessInMorphic.pdf). > I also wrote http://stackoverflow.com/a/4410189/424245 which should give a > taste and also answers your question more directly. HTH. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spec-Understandability-tp4778370p4785597.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > |
|
For me there is nothing that sucks more than having to type code to create a GUI in year 2014.... This a strong reason why I miss my days coding in Delphi so much. at least halos try to compensate for that partly.I love halos please dont remove them, good thing they suck for you, they rock for me. The fact that I can close a problematic morph that refuses to exit, by bringing its halo and clicking x , is enough reason to keep them around for me. I love the idea of halos the idea that you can hack any gui with simple actions, with no code invloved, and resynthesised it is definetly something I find immensely useful though the implementation of halos is far from ideal. On Tue, Oct 21, 2014 at 9:18 AM, stepharo <[hidden email]> wrote: Note that halo implementation sucks! |
|
|
kilon alios wrote:
> For me there is nothing that sucks more than having to type code to > create a GUI in year 2014.... This a strong reason why I miss my days > coding in Delphi so much. > > at least halos try to compensate for that partly.I love halos please > dont remove them, good thing they suck for you, they rock for me. I think you misread it. The key word is the "implementation" sucks. It seems Bloc is cleaning the implementation, not removing the functionality. -ben > The > fact that I can close a problematic morph that refuses to exit, by > bringing its halo and clicking x , is enough reason to keep them around > for me. > > I love the idea of halos the idea that you can hack any gui with simple > actions, with no code invloved, and resynthesised it is definetly > something I find immensely useful though the implementation of halos is > far from ideal. > > On Tue, Oct 21, 2014 at 9:18 AM, stepharo <[hidden email] > <mailto:[hidden email]>> wrote: > > Note that halo implementation sucks! > In Bloc alain clean it and he is able to plug halos and package them > cleanly. > > In addition in Bloc he took the decision not to implement for now > the direct creation of certain widget because > this kind of feature leads to spaghetti dependencies. > > Stef > > > > On 20/10/14 20:35, Sean P. DeNigris wrote: > > Ralph Boland wrote > > I am not in the habit of using halos, not really sure what > they are for. > But your description implies they are quite useful. > What does "bring up halos on and inspect a button to see > how to duplicate > its action" mean? Could you please describe in step by step > detail. > > Hi Ralph! I think the best way to understand why Morphic is > revolutionary is > to read the papers of its creators (e.g. > http://web.media.mit.edu/~__jmaloney/papers/__DirectnessAndLivenessInMorphic__.pdf > <http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLivenessInMorphic.pdf>). > I also wrote http://stackoverflow.com/a/__4410189/424245 > <http://stackoverflow.com/a/4410189/424245> which should give a > taste and also answers your question more directly. HTH. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Spec-__Understandability-__tp4778370p4785597.html > <http://forum.world.st/Spec-Understandability-tp4778370p4785597.html> > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > |
|
|
I may have but then halos have been abandoned in pharo at least functionality wise , I have not seen any improvement to them from when I started using Squeak 2 years ago and if I remember there were once a time you had to enable them in pharo settings. Also both a gui builder for squeak and another for pharo have been abandonware . So it looks pharo is not doing well on GUI front especially when it has to compete with gui designers in visual basic, visual studio, QT, GTK and many more. On Tue, Oct 21, 2014 at 2:01 PM, Ben Coman <[hidden email]> wrote: kilon alios wrote: |
|
|
On 21/10/14 14:20, kilon alios wrote:
Why are you saying that. You can get halos on any morph, just halos do not show up when you do not want them.
Did you ever look at the code of Halos? Halos are not defined per Morph but in a global tables. So we started to clean them. Do you think that spec is nothing in terms of dev. Give me 1/1000 of the ressources put on one of this project and we will have a real UIBuilder. Stef
|
|
|
In reply to this post by Ralph Boland
Ralph Boland wrote:
> > Besides error intractability, there is also a cost to understanding the > > system via exploration - a glorious benefit of Morphic. In the past, one > > only had to bring up halos on and inspect a button to see how to > duplicate > > its action. Now, to see what happens when one presses Versionner's > "Commit > > the project" button, you have to drill down in the inspector from > > aButtonXyzMorph -> model -> actionHolder -> value, a tedious and opaque > > process. > > > Of course, I'm not in any way against Spec or its goals, just sharing my > > unfolding experience using it. > > I'm running Squeak 4.0 but I assume my question still applies. If not, > other > Pharo users might want to know. > > I am not in the habit of using halos, not really sure what they are > for. But your description implies they are quite useful. > What does "bring up halos on and inspect a button to see how to duplicate > > its action" mean? Could you please describe in step by step detail. > > Ralph Boland Say you wanted your application to add a new package to the system. So you wonder how would to do that. Well... the system already does it! Right click in the first pane of the System Browser and you get a menu it <Add package...>. So why not just copy how that does it? But how do you look under the hood to see how it works you ask? Halos to the rescue! Hold the key combination to invoke halos and click on the menu item (varies between platforms, mac is <shift-option>, win is <shift-alt>) so that "ToggleMenuItemMorph" shows as the object type the halos are related to. On the right click the spanner "Debug" icon, and <inspect morph>. Scroll down looking for something that looks like a relevant method call (in this case 'target' contains [ target addPackge ]. #addPackage looks a likely candidate, so browse implementors and put a "self halt" at the top of the methods. Then back in the System Browser, invoke the <Add package...> menu item, and the debugger appears. Now you can trace through the execution of the system code that creates package. As an example, nothing beats real-life code. ----- Another use I have is sometimes to go World > System, use the Duplicate Halo on the <Enable halt/inspect once> menu item to drag it onto the background and using it as a button. HTH -ben |
|
|
In reply to this post by stepharo
I am saying because of my experience with halos , I have not seen anything new added to them or improved the last 2 years I am using Pharo.
No why would I need to looks at the code of halos ? I am its user not its developer. It great you clean the code of Halos but what that means to me as user ? Not much I am afraid.
Thats the problem I see many very good projects like Spec , PharoLauncher, Pillar, AsmJit, Nativeboost , Athens , Opal and the list goes on and on. But I see no interest in having a UIBuilder. Apparently GUI designers are very important for most IDEs out there and judging from the developers using them I would say also most developers but is not for Pharo. Why ? You say you want the resources of 1/1000 do you really say that you need more than 10 developers to make a UIBuilder ? Here examples of very small development teams that have produced capable IDEs with GUI designers included and the list goes on... I dont think that any of them had more than 1 -2 and certainly they were not full time devs. Gambas alone is one developer effort for the entire IDE, language, libraries, GUI designer etc etc. Why such small development teams do dare to implement features that huge IDEs do have ? Mainly because it usually comes down to small teams, take a look at Visual Basic for example, I was reading its history recently and found out that VB was no Microsoft invention (surprise - surprise) but there was actually a very small company that create it as a product that then they were hired from Microsoft. Delphi has a small development team as well, actually it was single developer that leaded the effort and was mainly responsible for its creation. So add this to one of my ranting and one of my complains. I love spec , I love nativeboost , I love Playground and new GT tools but none of these will ever start to compete with the usefulness of having a GUI designer when up to 50% of a modern GUI based apps code is creating and managing that GUI. The problem with Pharo's GUI designer is not that it sucks, its undocumented , it severely lacks in features. But that it simple does not exist. And without good GUI designer and an undocumented GUI API my remark that on the GUI front Pharo is not in a good state is as honest as it can be. On the other hand on other fronts, like web interfacing, databases, calling c libraries , vector graphics, unicode , true type fonts, JIT VM even 64 bit Pharo has made a lot more significant progress. So apparently Pharo resources wise seems to do great. Actually I am impressed how fast it progress forward , its amazing. |
|
|
2014-10-21 15:20 GMT-03:00 kilon alios <[hidden email]>:
Building a good GUI designer is one of those problems where you cannot "solve" with 1-2 unexperienced programmers (and I am not talking about of confident programmers, I mean real experience). Is not about just painting widgets, is about layered APIs, application integration, extending specialized widgets, how to integrate second party widgets, portability, usability, etc. It is a domain where you cannot support the whole learning curve of a post-doc, and expect to see successful results. In short: You have to hire experienced developers.
I didn't check but I wonder how they perform with resizing layouts? Do they use spacers? Do they use constraints?
Yes, and I prefer not having a GUI builder than having a bad one.
|
|
|
In reply to this post by kilon.alios
2014-10-21 14:20 GMT+02:00 kilon alios <[hidden email]>:
abandoned by developers or users?
more important than a gui designer is actually a gui library/toolkit. glamour, spec, athens, txtext, morph cleanup ... I think pharo does a great job on the GUI front. |
|
|
In reply to this post by hernanmd
I don't know/ remember for the other 2 (I have used them a couple of times long time ago) but Lazarus is basically an open source recreation of Delphi so those are pretty standard features. Even the standard library of Delphi has been ported to Lazarus / Free Pascal and it directly support specific Delphi versions. What you describe are standard features for most if not all GUI designers anyway. In Delphi I vaguely remember they were called anchors, you could pin them on a specific layout or choose sides or pin them in absolute positions though the last option was the least desirable if you wanted an easily resizable interface but overall you had tons of options. I remember the Delphi ("Mastering Delphi 6") book have once bought around 1000 pages , I still have it with me, 300 pages was the designer itself. But I dont count in the overall architecture where everything worked with drag and drop. So basically if you wanted to add a database engine inside your app , the engine was represented as a GUI button you drag and drop on top of the form of your app like any other GUI element but of course it was not visible when you run the app. Delphi is minimising code this way which is paradigm that Lazarus follows very closely too. So the designer went and still is going far beyond to just designing GUIs. Of course I dont expect something of such power in Pharo, actually not even Visual Studio has been able to compete with Delphi in RAD (Rapid Application Development) or even its main competitor Visual Basic. Borland was very powerful and quite well funded company with very big experience on programming languages and IDEs. Unfortunately like Visual Basic they lost traction when Java came out and Delphi was sold to a much smaller company. But still Delphi is quite popular. On the other hand modern IDEs do have many of these features. I was mainly talking about basic GUI designers. Draging , droping, resizing, setting layouts and constraints and at least having access to basic widgets for fast creation of GUI is absolute essential for a GUI based IDE like Pharo. You can't work as fast with code for GUI design. Its very slow and this is why GUI designers have been so popular and considered standard practice. |
|
|
2014-10-21 16:51 GMT-03:00 kilon alios <[hidden email]>:
I remember too but in those builders you mention you were not using constraints, you are just aligning by snapping widgets. Most GUI builders do not include a built-in constraint-based solver. They are difficult to implement, and maintain (over-constraints are a symptom of a tedious UI design process too). High-level constraints for automatic layout is a relatively active research topic.
Agree, but if your priority is having a GUI Builder, Pharo is not the best choice today. But you have MT GUI Builder, Smalltalk/X GUI Painter, Cincom GUI Painter Tool, Dolphin View Composer, etc. Cheers, Hernán |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |