On 12.02.2011, at 13:57, Esteban Lorenzano wrote: > I'm sorry but I disagree. > XML as a meta-language is old, bad and shit. > If you say XML is no-go shouldn't you present an alternative at the same time? Norbert > readable=good > xml=really bad (and not-readable either, most of the times... unless you are some kind of cyborg) > > El 12/02/2011, a las 7:35a.m., nullPointer escribió: > >> >> My knowledge of Smalltalk/Squeak/Pharo is limited, but I believe somethings. >> >> 1- I believe Pharo/Squeak needs a different way for "render" the morphs. I >> suppose Rome go to that direction. >> >> 2- A language, human readable, for define the UI. I believe than XAML or >> XUL, based on XML, be good examples. And connect the UI to >> Controller/Presenter/ViewModel of same way, through bindings, Commands etc >> like WPF. >> >> The code generated for designer of VW or Smalltalk/X don´t readable and >> updatable for a human, only for the same designer mechanism. Don´t works of >> example. It´s a OLD way, is a BAD way, is a shit way. >> >> 3- Implements a set of widgets. That is not difficult I believe. The main >> problem is the way of connect that widgets with data. I repeat above, >> bindings mechanism from WPF is a good-good example. >> Perhaps exists some controls for build... numeric controls with formatable >> values, datatime controls, grids (nobody needs a grid control on >> Pharo/Smalltalk?? I´m unique? How I can create a enterprise app without >> that?) >> >> 4- Implement the designer. BUT, that step don´t is needed if the language >> for define the UI is a standard. Exists many designers of XAML and some for >> XUL languages. Somebody could use that designers for build the UI, and add >> the XML in a spec method on Smalltalk image. We need only a "reader" for >> interpret the XAML code and build the morphic structure (or HTML render >> structure) >> >> >> My conseil is: if we need implement set of widgets and a language for design >> UI is much more recommend base us in the new "way of do", don´t the old. >> >> Regards. >> -- >> View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302570.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > |
CONTENTS DELETED
The author has deleted this message.
|
On 12.02.2011, at 14:20, Hilaire Fernandes wrote: > Le 12/02/2011 14:14, Norbert Hartl a écrit : >> >> On 12.02.2011, at 13:57, Esteban Lorenzano wrote: >> >>> I'm sorry but I disagree. >>> XML as a meta-language is old, bad and shit. >>> >> If you say XML is no-go shouldn't you present an alternative at the same time? > > Lisp, Scheme or even Smalltalk :) You are right. I didn't want to give suggestions :) I would have said. If it doesn't need to be cross language and it should be structured and readable than smalltalk is probably the best solution. To me Lisp classifies at the level of XML if it comes to readability :) Norbert |
In reply to this post by NorbertHartl
Yes, Smalltalk :)
You can do exactly the same in a much better way. Last 10 years the world tried to use XML to... well, pretty much everything: as a meta-language to many DSLs, like XUL, XAML, but also for configurations, state-machines, etc. And it was a big failure... and the best example is that even in communities where the overcomplicated stuff is "the way to go" (like java), are leaving that, replacing it for most "in-code" ways (for example, using "scripting" languages). So... why are we going to go back on something the world is leaving? Of course, as much other "dead" things, XML is going to be around a lot of time... but is not anymore in the innovation line, and everybody can note that. think on something like: <StackPanel> <TextBlock Margin="20">Welcome to the World of XAML</TextBlock> <Button Margin="10" HorizontalAlignment="Right">OK</Button> </StackPanel> how it would be in Smalltalk? there are several ways... let's take the "Seaside way": xaml stackPanel: [ xaml textBlock margin: 20; with: 'Welcome to the World of XAML'. xaml button margin: 10; horizontalAlignment: #right; with: 'OK'. ] what's better? and that's only "wrapping" xaml... of course we can have something a lot better than just render xaml (like really composing objects)... but that was just an example :) Cheers, Esteban El 12/02/2011, a las 10:14a.m., Norbert Hartl escribió: > > On 12.02.2011, at 13:57, Esteban Lorenzano wrote: > >> I'm sorry but I disagree. >> XML as a meta-language is old, bad and shit. >> > If you say XML is no-go shouldn't you present an alternative at the same time? > > Norbert >> readable=good >> xml=really bad (and not-readable either, most of the times... unless you are some kind of cyborg) >> >> El 12/02/2011, a las 7:35a.m., nullPointer escribió: >> >>> >>> My knowledge of Smalltalk/Squeak/Pharo is limited, but I believe somethings. >>> >>> 1- I believe Pharo/Squeak needs a different way for "render" the morphs. I >>> suppose Rome go to that direction. >>> >>> 2- A language, human readable, for define the UI. I believe than XAML or >>> XUL, based on XML, be good examples. And connect the UI to >>> Controller/Presenter/ViewModel of same way, through bindings, Commands etc >>> like WPF. >>> >>> The code generated for designer of VW or Smalltalk/X don´t readable and >>> updatable for a human, only for the same designer mechanism. Don´t works of >>> example. It´s a OLD way, is a BAD way, is a shit way. >>> >>> 3- Implements a set of widgets. That is not difficult I believe. The main >>> problem is the way of connect that widgets with data. I repeat above, >>> bindings mechanism from WPF is a good-good example. >>> Perhaps exists some controls for build... numeric controls with formatable >>> values, datatime controls, grids (nobody needs a grid control on >>> Pharo/Smalltalk?? I´m unique? How I can create a enterprise app without >>> that?) >>> >>> 4- Implement the designer. BUT, that step don´t is needed if the language >>> for define the UI is a standard. Exists many designers of XAML and some for >>> XUL languages. Somebody could use that designers for build the UI, and add >>> the XML in a spec method on Smalltalk image. We need only a "reader" for >>> interpret the XAML code and build the morphic structure (or HTML render >>> structure) >>> >>> >>> My conseil is: if we need implement set of widgets and a language for design >>> UI is much more recommend base us in the new "way of do", don´t the old. >>> >>> Regards. >>> -- >>> View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302570.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > > |
On 12.02.2011, at 14:32, Esteban Lorenzano wrote: > Yes, Smalltalk :) > You can do exactly the same in a much better way. > > Last 10 years the world tried to use XML to... well, pretty much everything: as a meta-language to many DSLs, like XUL, XAML, but also for configurations, state-machines, etc. And it was a big failure... and the best example is that even in communities where the overcomplicated stuff is "the way to go" (like java), are leaving that, replacing it for most "in-code" ways (for example, using "scripting" languages). So... why are we going to go back on something the world is leaving? Of course, as much other "dead" things, XML is going to be around a lot of time... but is not anymore in the innovation line, and everybody can note that. > > think on something like: > > <StackPanel> > <TextBlock Margin="20">Welcome to the World of XAML</TextBlock> > <Button Margin="10" HorizontalAlignment="Right">OK</Button> > </StackPanel> > > how it would be in Smalltalk? there are several ways... let's take the "Seaside way": > > xaml stackPanel: [ > xaml textBlock > margin: 20; > with: 'Welcome to the World of XAML'. > xaml button > margin: 10; > horizontalAlignment: #right; > with: 'OK'. ] > > what's better? > and that's only "wrapping" xaml... of course we can have something a lot better than just render xaml (like really composing objects)... but that was just an example :) > For the rest of your mail. I don't agree at all to your general statement about xml but to this regard (the ui stuff) I agree fully. Norbert > El 12/02/2011, a las 10:14a.m., Norbert Hartl escribió: > >> >> On 12.02.2011, at 13:57, Esteban Lorenzano wrote: >> >>> I'm sorry but I disagree. >>> XML as a meta-language is old, bad and shit. >>> >> If you say XML is no-go shouldn't you present an alternative at the same time? >> >> Norbert >>> readable=good >>> xml=really bad (and not-readable either, most of the times... unless you are some kind of cyborg) >>> >>> El 12/02/2011, a las 7:35a.m., nullPointer escribió: >>> >>>> >>>> My knowledge of Smalltalk/Squeak/Pharo is limited, but I believe somethings. >>>> >>>> 1- I believe Pharo/Squeak needs a different way for "render" the morphs. I >>>> suppose Rome go to that direction. >>>> >>>> 2- A language, human readable, for define the UI. I believe than XAML or >>>> XUL, based on XML, be good examples. And connect the UI to >>>> Controller/Presenter/ViewModel of same way, through bindings, Commands etc >>>> like WPF. >>>> >>>> The code generated for designer of VW or Smalltalk/X don´t readable and >>>> updatable for a human, only for the same designer mechanism. Don´t works of >>>> example. It´s a OLD way, is a BAD way, is a shit way. >>>> >>>> 3- Implements a set of widgets. That is not difficult I believe. The main >>>> problem is the way of connect that widgets with data. I repeat above, >>>> bindings mechanism from WPF is a good-good example. >>>> Perhaps exists some controls for build... numeric controls with formatable >>>> values, datatime controls, grids (nobody needs a grid control on >>>> Pharo/Smalltalk?? I´m unique? How I can create a enterprise app without >>>> that?) >>>> >>>> 4- Implement the designer. BUT, that step don´t is needed if the language >>>> for define the UI is a standard. Exists many designers of XAML and some for >>>> XUL languages. Somebody could use that designers for build the UI, and add >>>> the XML in a spec method on Smalltalk image. We need only a "reader" for >>>> interpret the XAML code and build the morphic structure (or HTML render >>>> structure) >>>> >>>> >>>> My conseil is: if we need implement set of widgets and a language for design >>>> UI is much more recommend base us in the new "way of do", don´t the old. >>>> >>>> Regards. >>>> -- >>>> View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302570.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >> >> > > |
In reply to this post by Stéphane Ducasse
Am 2011-02-12 um 09:54 schrieb Stéphane Ducasse:
> tobias > > if you want to think that I'm an asshole and I do not want to have a better UI, you are free to think that. Please rest assured that this is _not_ the case. I just was astonished that you denied the usability of the Gui builder with just few very general words. > Now this is not the case. So if you can read my mail with the eyes of somebody that fight daily to make the system > nicer, better, smaller.... I know. > >>>>> >>>>> So there is an engineering effort needed. >> >> oO did other pharo-development _not_ involve engineering? > > Yes so who is standing up and saying ok I will allocate one month to make sure that this is well integrated? However, if you want it in Pharo, thats the way to go. Think of Seaside on any non-Pharo. It is just the same. > >>>>> >>> How do they compare with announcements and event and #changed >> >> Had you read the Wiki, you would know. >> “convenient, lightweight and thread-safe callbacks” >> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals >> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#FeatureComparison > > Yes. Now the question is do we want that in addition to > - event, > - announcement > - changed > > We are working ***HARD*** to remove event and system changenotifier. > Design is not layering, it is about bringing the right infrastructure in place. > So if signals are important/good then they should be not in competition to other but either integrated into > or we should migrate the code to the other abstractions. Probably. However, cirticising initially other goals for not being Pharo’s isn’t fair, IMHO. > > >>> In the case of the UIBuilder of void, >> >> Void? > The nikname of the personn He is called Marcel and posted elsewhere in the thread. >> >>> there are new widgets that extend existing ones but >>> It would be better to not subclass and get better widgets. >> >> Interesting, Because it is what polymorph has done for years. > > Yes and this is why we do not want that. > Even for polymorph the goal is to merge everything and get one set of excellent widgets based on an excellent core. No Objection. > > >>> May be fixing copy/postcopy, >> >> what? > > in pharo we use postcopy So does Squeak. > >>> use of _, >> >> what? > > ??? > we should not have _ > rob vens told me that there are _ in the BUilder code I doubt that there are _ assignments. > > >>> ...... references to Preferences,.... >> >> Then, what about a -PharoCompat package? > > I did not see it. No, I mean, What about _creating_ a PharoCompat package that matches your style of preferences. > >> >>> This kind of work. >> >> Pleas let me quote your initial mail: >>>>> We cannot stack libraries. >> >> I'd like to understand that, please. > > > As I said, we do not want to have four ways to emit announcements, we need one cool widgets set (merging the best of what exist), in the past we had 4 different ButtonMorph. I want one excellent one. So to get there it will take engineering time. > Just to evaluate solution. Thats quite clear and I concur. The point is, you would have to do this with or without the builder. Oh, and for this and my previous emails: No offence meant. So Long, -Tobias |
> > > >>> In the case of the UIBuilder of void, > >> > >> Void? > > The nikname of the personn > > He is called Marcel and posted elsewhere in the thread. I think that Stef is refering to nullPointer that also worked on a GUI Builder Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Am 2011-02-12 um 18:31 schrieb Miguel Cobá:
>>>>> In the case of the UIBuilder of void, >>>> >>>> Void? >>> The nikname of the personn >> >> He is called Marcel and posted elsewhere in the thread. > > I think that Stef is refering to nullPointer that also worked on a GUI > Builder Ok, thanks for clarification. So Long, -tobias |
In reply to this post by EstebanLM
Create the UI with plain Smalltalk code have problems... my UIBuilder use that system and have limitations for limit of lityerals in a spec method, and other problems.
Another alternative is the VW or Smalltalk/X mechanism, no readable, no updatable; only could be modified for the same designer routine. XAML is a standard (or XUL). Allow define the UI, but too allow define bindings, templates, commands etc for work with the controller/presenter/viewmodel. For do the same in any language, with plain code, you need much more code lines. A example with only a textbox and a label don´t works. Try build a view with three grids, many fields, bindings, events, tranmsformations, styles... and then compare the number of code lines from a way and another. And compare too the readable result...!!! And is possible create it with external designers; a Smalltalk designer is not needed. Only a XAML reader-builder is needed, and a set of widgets for work of that way. Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then anyway is bad. Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. Lo digo en castellano porque no sé expresarlo en inglés. Regards. |
No, I don't believe anything except smalltalk is bad. Just XML. I worked with Java, C# and a lot of XML to know that.
Don't be confused... I'm not talking against XML alternatives because of microsoft or anything, I have serious technical complains against it. Also, XUL is not microsoft's and I'm opposing to it as strongly as XAML (but Seaside-XUL is cool, he). Said so... i'm not against build an XAML importer or so, but I think you'll find a lot of several issues to solve, and it will maybe impossible :) <Spanish here> (yeah... bad joke) Además... no lo defiendo porque crea que Smalltalk es mejor siempre, solo que en este caso, es mucho mejor que usar XML. Trabajo en la industria desde hace 18 años y solo hace 4 con Smalltalk, y además todavía hoy trabajo haciendo consultoría de arquitectura de proyectos hechos en Java o C#... se perfectamente de que estoy hablando... no estoy en contra ni de Oracle ni de Microsoft... simplemente, creo que usar XML es una mala alternativa, no te vayas por las ramas, plis :) </Spanish here> Cheers, Esteban El 12/02/2011, a las 2:59p.m., nullPointer escribió: > > Create the UI with plain Smalltalk code have problems... my UIBuilder use > that system and have limitations for limit of lityerals in a spec method, > and other problems. > > Another alternative is the VW or Smalltalk/X mechanism, no readable, no > updatable; only could be modified for the same designer routine. > > XAML is a standard (or XUL). Allow define the UI, but too allow define > bindings, templates, commands etc for work with the > controller/presenter/viewmodel. For do the same in any language, with plain > code, you need much more code lines. A example with only a textbox and a > label don´t works. Try build a view with three grids, many fields, bindings, > events, tranmsformations, styles... and then compare the number of code > lines from a way and another. And compare too the readable result...!!! > > And is possible create it with external designers; a Smalltalk designer is > not needed. Only a XAML reader-builder is needed, and a set of widgets for > work of that way. > > Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then > anyway is bad. > > Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan > acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que > nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. > Lo digo en castellano porque no sé expresarlo en inglés. > > Regards. > -- > View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
In reply to this post by Tobias Pape
On Feb 12, 2011, at 6:22 PM, Tobias Pape wrote: > Am 2011-02-12 um 09:54 schrieb Stéphane Ducasse: >> tobias >> >> if you want to think that I'm an asshole and I do not want to have a better UI, you are free to think that. > > Please rest assured that this is _not_ the case. ok good > I just was astonished that you denied the usability of > the Gui builder with just few very general words. No I just evaluate MY time and what I'm able to achieve >>>>>> >>>>>> Yes so who is standing up and saying ok I will allocate one month to make sure that this is well integrated? > > However, if you want it in Pharo, thats the way to go. > Think of Seaside on any non-Pharo. It is just the same. Yes so this is why I said about my time. >>>>>> >> >> Yes. Now the question is do we want that in addition to >> - event, >> - announcement >> - changed >> >> We are working ***HARD*** to remove event and system changenotifier. >> Design is not layering, it is about bringing the right infrastructure in place. >> So if signals are important/good then they should be not in competition to other but either integrated into >> or we should migrate the code to the other abstractions. > > Probably. However, cirticising initially other goals for not being > Pharo’s isn’t fair, IMHO. This is not what I did. I just evaluate: ok if I want that I need X, Z, K so my message was ok guys do not dream we cannot just include the builder that you and me would love to have. There is a lot of work to be done to arrive to that stage. >>>> In the case of the UIBuilder of void, >>> >>> Void? >> The nikname of the personn > > He is called Marcel and posted elsewhere in the thread. Ok this was nullPointer that I wanted to say. Not marcel because I know the first name of marcel. >>>> >> Yes and this is why we do not want that. >> Even for polymorph the goal is to merge everything and get one set of excellent widgets based on an excellent core. > > No Objection. > >>>> >>>> >> in pharo we use postcopy > > So does Squeak. Ok good to know one less point to check. >>>> > > I doubt that there are _ assignments. I do not know. Rob ask me how to load code without _ > No, I mean, What about _creating_ a PharoCompat > package that matches your style of preferences. Ah this would be good. >> > Thats quite clear and I concur. > The point is, you would have to do this with or without the builder. yes except that I have to check the widgets and check that. > Oh, and for this and my previous emails: No offence meant. No problem just a question: are the new widgets relying on signal? Because I would have to really study signal to imagine what we can do? Or are signal use to plug together widgets? > > So Long, > -Tobias > > |
In reply to this post by gerard alis
On Feb 12, 2011, at 6:59 PM, nullPointer wrote: > > Create the UI with plain Smalltalk code have problems... my UIBuilder use > that system and have limitations for limit of lityerals in a spec method, > and other problems. No because one single array can contain all the specs. They do that in VW since 1997 at least and it work well - you get a spec object tree - you can generate the widgets you want - morphic - html5 > Another alternative is the VW or Smalltalk/X mechanism, no readable, This is exactly the same than xml except that you do not need an xml parser to get the objects > no > updatable; ??? > only could be modified for the same designer routine. ??? > XAML is a standard (or XUL). Allow define the UI, but too allow define > bindings, templates, commands etc for work with the > controller/presenter/viewmodel. As I already said it multiple time, XML or UISpec are the same except that UISpec you get a real tree with potentially sspecific nodes. All the rest you can do exactly the same than wiht XML One day I will prove that to you. > For do the same in any language, with plain > code, you need much more code lines. A example with only a textbox and a > label don´t works. Try build a view with three grids, many fields, bindings, > events, tranmsformations, styles... and then compare the number of code > lines from a way and another. And compare too the readable result...!!! > > And is possible create it with external designers; a Smalltalk designer is > not needed. Only a XAML reader-builder is needed, and a set of widgets for > work of that way. > > Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then > anyway is bad. Not at all. We do not need xml to represent UISpec!!!!!!!! We can have plain objects and just call them UISpec. We can build a nice visitor on the spec tree and do a lot of things with it. > > Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan > acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que > nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. > Lo digo en castellano porque no sé expresarlo en inglés. > > Regards. > -- > View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
In reply to this post by EstebanLM
xml is good a simple interexchange format. Now when you have you xml stream you have to map your nodes (different to objects) so for UISPec you can just get a parser and object builder for free. NO need to load XMLSupport. read my VW examples to understand. In VW you can click on a button and see the spec or see the rendering of the spec in your code pane and this is just based on spec objects that are stored in arrays. Simple! This is not because the world does not have a nice synatx with can be used to get xml description that we should use xml everywhere. (Book title: 'Zorro'; year: 1969; pages: 230) Is better than <xml tage \xml> why because I can do doit and get a book object on the first expression with the second I have to do XMLDomParser on ::.... parse..... map to books..... I know I'm saving some of my projects in XML and mapping is boring. Stef On Feb 12, 2011, at 7:13 PM, Esteban Lorenzano wrote: > No, I don't believe anything except smalltalk is bad. Just XML. I worked with Java, C# and a lot of XML to know that. > Don't be confused... I'm not talking against XML alternatives because of microsoft or anything, I have serious technical complains against it. Also, XUL is not microsoft's and I'm opposing to it as strongly as XAML (but Seaside-XUL is cool, he). > > Said so... i'm not against build an XAML importer or so, but I think you'll find a lot of several issues to solve, and it will maybe impossible :) > > <Spanish here> (yeah... bad joke) > Además... no lo defiendo porque crea que Smalltalk es mejor siempre, solo que en este caso, es mucho mejor que usar XML. > Trabajo en la industria desde hace 18 años y solo hace 4 con Smalltalk, y además todavía hoy trabajo haciendo consultoría de arquitectura de proyectos hechos en Java o C#... se perfectamente de que estoy hablando... no estoy en contra ni de Oracle ni de Microsoft... simplemente, creo que usar XML es una mala alternativa, no te vayas por las ramas, plis :) > </Spanish here> > > Cheers, > Esteban > > El 12/02/2011, a las 2:59p.m., nullPointer escribió: > >> >> Create the UI with plain Smalltalk code have problems... my UIBuilder use >> that system and have limitations for limit of lityerals in a spec method, >> and other problems. >> >> Another alternative is the VW or Smalltalk/X mechanism, no readable, no >> updatable; only could be modified for the same designer routine. >> >> XAML is a standard (or XUL). Allow define the UI, but too allow define >> bindings, templates, commands etc for work with the >> controller/presenter/viewmodel. For do the same in any language, with plain >> code, you need much more code lines. A example with only a textbox and a >> label don´t works. Try build a view with three grids, many fields, bindings, >> events, tranmsformations, styles... and then compare the number of code >> lines from a way and another. And compare too the readable result...!!! >> >> And is possible create it with external designers; a Smalltalk designer is >> not needed. Only a XAML reader-builder is needed, and a set of widgets for >> work of that way. >> >> Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then >> anyway is bad. >> >> Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan >> acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que >> nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. >> Lo digo en castellano porque no sé expresarlo en inglés. >> >> Regards. >> -- >> View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > |
In reply to this post by Stéphane Ducasse
>> no >> updatable; >??? >> only could be modified for the same designer routine. >??? Can you modify manually the code generated for the UI Painter of VW? I´m not; I´m not mutant :) The use of XAML or XUL is for portability. Exists many tools for design a GUI in XAML or XUL. The perfect GUI designer already exists. In all Smalltalks implementations, ALL, don´t exists a best GUI Builder of that tools. I don´t understand how we can think could create one easily, of the same level, if not exists in any Smalltalk, include commercials. The UI Painter and widgets of VW is pathetical... that is the example to copy??? Well, we can still dreaming. And talking. Regards. |
2011/2/12 nullPointer <[hidden email]>:
> > >>> no >>> updatable; > >>??? > >>> only could be modified for the same designer routine. > >>??? > > Can you modify manually the code generated for the UI Painter of VW? I´m > not; I´m not mutant :) > > The use of XAML or XUL is for portability. Exists many tools for design a > GUI in XAML or XUL. > The perfect GUI designer already exists. In all Smalltalks implementations, > ALL, don´t exists a best GUI Builder of that tools. I don´t understand how > we can think could create one easily, of the same level, if not exists in > any Smalltalk, include commercials. The UI Painter and widgets of VW is > pathetical... that is the example to copy??? > Take a look at WindowBuilder Pro, is the most professional GUI Builder for Smalltalk. Cheers, Hernán |
WindowBuilder is impressive. I'm not sure how to clean room it though.
If the concern is over the serialization of objects, has anyone considered SIXX for that? Doing that could give us something similar to the Dolphin ViewComposer but clearly of distinct origin. To the result, we could add some features of WindowBuilder (adding event handlers, etc.). Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Hernán Morales Durand [[hidden email]] Sent: Saturday, February 12, 2011 5:04 PM To: [hidden email] Subject: Re: [Pharo-project] A new GUI visual designer 2011/2/12 nullPointer <[hidden email]>: > > >>> no >>> updatable; > >>??? > >>> only could be modified for the same designer routine. > >>??? > > Can you modify manually the code generated for the UI Painter of VW? I´m > not; I´m not mutant :) > > The use of XAML or XUL is for portability. Exists many tools for design a > GUI in XAML or XUL. > The perfect GUI designer already exists. In all Smalltalks implementations, > ALL, don´t exists a best GUI Builder of that tools. I don´t understand how > we can think could create one easily, of the same level, if not exists in > any Smalltalk, include commercials. The UI Painter and widgets of VW is > pathetical... that is the example to copy??? > Take a look at WindowBuilder Pro, is the most professional GUI Builder for Smalltalk. Cheers, Hernán |
In reply to this post by hernanmd
my 0.002 cents:
- XML suxx - we need better UI - we need good graphics engine - we need good event system - we need to evaluate all alternatives :) -- Best regards, Igor Stasenko AKA sig. |
XML suxxx....
XAML or XUL suxxxs too? regards. |
In reply to this post by EstebanLM
On 12.02.2011, at 19:13, Esteban Lorenzano wrote: > No, I don't believe anything except smalltalk is bad. Just XML. I worked with Java, C# and a lot of XML to know that. > Don't be confused... I'm not talking against XML alternatives because of microsoft or anything, I have serious technical complains against it. Also, XUL is not microsoft's and I'm opposing to it as strongly as XAML (but Seaside-XUL is cool, he). > Esteban, it doesn't matter to me _why_ you are arguing like you do. I'm interested in hearing _what_ you have to say. Stating that you have a lot of experience (I have no doubt about it) and that you have good reasons does not make me believe/being convinced in any way. Just tell some of your good reasons so I can get anything from it. > Said so... i'm not against build an XAML importer or so, but I think you'll find a lot of several issues to solve, and it will maybe impossible :) > why? > <Spanish here> (yeah... bad joke) > Además... no lo defiendo porque crea que Smalltalk es mejor siempre, solo que en este caso, es mucho mejor que usar XML. > Trabajo en la industria desde hace 18 años y solo hace 4 con Smalltalk, y además todavía hoy trabajo haciendo consultoría de arquitectura de proyectos hechos en Java o C#... se perfectamente de que estoy hablando... no estoy en contra ni de Oracle ni de Microsoft... simplemente, creo que usar XML es una mala alternativa, no te vayas por las ramas, plis :) > </Spanish here> > Well, my understanding of this is probably of the level of reading a french text :) Norbert > Cheers, > Esteban > > El 12/02/2011, a las 2:59p.m., nullPointer escribió: > >> >> Create the UI with plain Smalltalk code have problems... my UIBuilder use >> that system and have limitations for limit of lityerals in a spec method, >> and other problems. >> >> Another alternative is the VW or Smalltalk/X mechanism, no readable, no >> updatable; only could be modified for the same designer routine. >> >> XAML is a standard (or XUL). Allow define the UI, but too allow define >> bindings, templates, commands etc for work with the >> controller/presenter/viewmodel. For do the same in any language, with plain >> code, you need much more code lines. A example with only a textbox and a >> label don´t works. Try build a view with three grids, many fields, bindings, >> events, tranmsformations, styles... and then compare the number of code >> lines from a way and another. And compare too the readable result...!!! >> >> And is possible create it with external designers; a Smalltalk designer is >> not needed. Only a XAML reader-builder is needed, and a set of widgets for >> work of that way. >> >> Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then >> anyway is bad. >> >> Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan >> acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que >> nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. >> Lo digo en castellano porque no sé expresarlo en inglés. >> >> Regards. >> -- >> View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > |
Just a comment: :) This reminds me of the way, the Smalltalk Image works – except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder.
But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that.
That is ironic, I think ^^ -- Sent from my DynaBook.
|
Free forum by Nabble | Edit this page |