My own two cents is that it would be a really smart idea for Cincom to
carve out a few man weeks of time to prototype a wxWidgets capability for VisualWorks. Make the bare essentials work, including any VM hooks that are needed. Then put this up on the public Store. Even if this isn't the official UI for VW in the future, it as least gives the community a chance to support it for their own use. It wouldn't be much of a stretch to say that Cincom owes us this much after having cancelled Pollock/Widgetry. -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Sat, Nov 28, 2009 at 2:53 PM, Thomas Sattler <[hidden email]> wrote: > I have been reading this thread, with a number of people weighing in with > their opinions. I have been away from Smalltalk for a while, but I > installed a recent 7.7 dev build on my Linux box. I spent half an hour > going through the product briefly, just to see what's changed. > > <rant> > Apparently not much. It looks like yes, Cincom HAS given up the desktop. > Here is what I found: > > - The Canvas Painter looks the same as it has for at least 15 years. It's > never been intuitive, and it's still not. For instance, select the "Drop > Target" tab and you get four fields labeled "Entry", "Over", "Exit", > "Drop". Yes, I know what they're for. Does a novice? How much effort > would it take to put a tooltip on each field, providing a little help to a > new person? > > - The icons on the Palette haven't been updated in, uh, maybe ever. > > - I select "Launcher Help" from the Launcher, and I get an ugly grey box > with a list, and at the bottom of the list it says "Move cursor over an item > for help information". I move my cursor over everything I see, and nothing > happens. > > - The AdHoc SQL window was awful 10 years ago, and it's awful now. When I > enter a query, if any of the returned fields are a timestamp, I can't see > the entire value. I have a field that contains "August 20, 2009 10:46:18 > am" and all I can see in that field is "August 20, 2" and it gets cut off. > Are you kidding? I remember complaining about this years ago. Nothing has > happened. You cannot resize the column widths in the output. When I was at > Morgan Stanley, I redid that app using the Aragon data set widget with tabs, > and I could keep a different frequently-run query open in each tab, and I > could rerun each query by hitting one key. Unfortunately I wrote this on > Morgan Stanley's dime and they did not permit me to contribute it back to > the product. But if I was able to do it, Cincom's engineers can do it > easily enough. > > - I don't know the status of the DLLCC parser, but when I was using it > frequently, it was years since I had a header file parse completely on the > first attempt. I would always get errors that I had to fix by hand, since > there were enhancements made to the world of header files that the parser > didn't know about. I don't know if this has been fixed because I don't deal > with those kinds of things any more, and I don't have a complicated header > file lying around that I can use for testing. > > - Under the "Settings" tool, the selection dropdown for "Look and Feel" > contains "Windows 95/NT" and "Windows 98/2000". Terrific. This just > screams out "I am an up-to-date system." > > > We all know the reason for this, of course. The UI received no attention > for a period of six years due to the Pollock debacle. I don't want to > mention names because it's not productive to do that, and everyone knows the > history. The first Pollock parcels were written to the Cincom Store > Repository in December 2001, and the effort was cancelled in November 2007. > That's six years of work that wasn't spent redoing the Canvas Painter. Six > years that wasn't spent rewriting the AdHoc SQL window. Or updating the > DLLCC parser. Or writing new "Look and Feel" packages to emulate operating > systems that came out in this century. Basically every issue with the > product can be directly traced back to Pollock, and the opportunity cost > involved in it. > > The comment for the "Pollock" bundle in the Cincom Store Repository says: > > "The goals of this new Framework are really quite simple. Make a GUI > Framework that maintains all of the goals of the current VisualWorks GUI, > that is flexible and capable enough to see us forward for at least the next > decade." > > If it was "really quite simple" it would have been done by now. It would > have been done years ago. There is nothing that's going to "see us forward > for at least the next decade." More than half a decade was wasted, > resulting in absolutely nothing. > > > Maarten Mostert made a point earlier today which caused me to write this: > >> The ones who advocate Smalltalk most of the time underline its mallability >> and dynamic character. >> If cincom is capable of underpinning a new modern UI's underneath 3000+ >> canvas type applications >> then you Cincom can go to Gartner and tell them He guys this is what "we" >> have been doing recently >> with user investements and dynamic languages. > > > He is right, of course, but there is a corollary to what he wrote, which is > this: We all talk about how productive Smalltalk is. But if an expert > Smalltalk engineer can't redo the UI in six years, maybe it's not as > productive as we have been led to believe. I would tend to think that there > were people evaluating Smalltalk at the time who noticed this, and came to > that conclusion. And the logical extension of that is: If we threw six > years of work into the garbage trying to rework the UI, then it's difficult > to see Cincom making a second attempt at it, so the UI we have now is the UI > we are going to have for a long, long time(I had suggested in the past to > look into redoing the UI using the wxWidgets package, but I was shot down > for reasons I don't recall now). > > I hope I am wrong about this, but this is the way things look from here. > > </rant> > > As I wrote at the beginning, I have been away from Smalltalk for a while, so > maybe there are things going on that I don't know about. > > I hope so. > > --Tom > > > > > On Sat, Nov 28, 2009 at 2:46 PM, Holger Kleinsorgen > <[hidden email]> wrote: >> >> Andre Schnoor wrote: >> > >> > Alan, >> > >> >> - Fonts were mentioned a couple of times >> > >> > From an engineer's perspective, native fonts might seem like a minor >> > matter of design only. Real world end users however expect to be able to >> > use the fonts they have installed on their computer (and sometimes paid >> > for), at least for printing and editing. >> > >> >> that's especially true for "modern" Unixes that use Xft/Treetype to >> display antialiased fonts. Actually, Freetype has been around for some >> years now. Together with the Motif look, it looks outdated. >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
2009/11/28 Carl Gundel <[hidden email]>:
> My own two cents is that it would be a really smart idea for Cincom to > carve out a few man weeks of time to prototype a wxWidgets capability > for VisualWorks. Why wxWidgets and not Qt? I just ask, I have no knowledge... But at least Qt should be considered:http://qt.nokia.com/developer/qt-roadmap Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I don't have anything against Qt. I've never heard of it before
now. :-) -Carl Gundel Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, easy web programming - http://www.runbasic.com On Nov 28, 2009, at 5:55 PM, Runar Jordahl <[hidden email]> wrote: > 2009/11/28 Carl Gundel <[hidden email]>: >> My own two cents is that it would be a really smart idea for Cincom >> to >> carve out a few man weeks of time to prototype a wxWidgets capability >> for VisualWorks. > > Why wxWidgets and not Qt? I just ask, I have no knowledge... But at > least Qt should be considered:http://qt.nokia.com/developer/qt-roadmap > > Runar vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Either would be better than what we have now. Both projects have already implemented a multi-platform UI solution. Since we, as Smalltalk developers, march under the banner of "Reuse", let's prove we mean it. Let's reuse what someone else has already done.
On Sat, Nov 28, 2009 at 6:04 PM, Carl Gundel <[hidden email]> wrote: I don't have anything against Qt. I've never heard of it before _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On Sat, Nov 28, 2009 at 4:38 PM, Thomas Sattler <[hidden email]> wrote: Either would be better than what we have now. Both projects have already implemented a multi-platform UI solution. Since we, as Smalltalk developers, march under the banner of "Reuse", let's prove we mean it. Let's reuse what someone else has already done. I'm not that familiar with either widget framework, and I don't know how much work either of them would be to support in VW. However, my concern would be backwards compatibility for existing customers. There are customers (that we've heard about on this thread) who have a significant investment in the current UI framework. How likely is it that they are going to be willing/able to port their applications to a new, incompatible GUI framework. Isn't that part of what killed Widgetry in the first place? It's all well and good for all of us to pontificate on what Cincom should do here, and I agree that there needs to be some work done in these areas, but we have to remember that they've got a significant installed base to consider when they look at these options. Randy -- Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
My suggestion was to provide the most basic support for wxWidgets or
similar mechanism, not to replace the legacy GUI framework. If the core is there to support the elementary widgets, events and callbacks then the community can add Smalltalk classes for the rest. I'm not sure that we aren't somewhat entitled to pontificate. We are Cincom's customers after all. -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Sat, Nov 28, 2009 at 10:08 PM, Randy Coulman <[hidden email]> wrote: > > On Sat, Nov 28, 2009 at 4:38 PM, Thomas Sattler <[hidden email]> > wrote: >> >> Either would be better than what we have now. Both projects have already >> implemented a multi-platform UI solution. Since we, as Smalltalk >> developers, march under the banner of "Reuse", let's prove we mean it. >> Let's reuse what someone else has already done. > > I'm not that familiar with either widget framework, and I don't know how > much work either of them would be to support in VW. > > However, my concern would be backwards compatibility for existing > customers. There are customers (that we've heard about on this thread) who > have a significant investment in the current UI framework. How likely is it > that they are going to be willing/able to port their applications to a new, > incompatible GUI framework. Isn't that part of what killed Widgetry in the > first place? > > It's all well and good for all of us to pontificate on what Cincom should do > here, and I agree that there needs to be some work done in these areas, but > we have to remember that they've got a significant installed base to > consider when they look at these options. > > Randy > -- > Randy Coulman > [hidden email] > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 29/11/2009, at 2:29 PM, Carl Gundel wrote: > My suggestion was to provide the most basic support for wxWidgets or > similar mechanism, not to replace the legacy GUI framework. If the > core is there to support the elementary widgets, events and callbacks > then the community can add Smalltalk classes for the rest. I think a better better choice would be to map Cocoa/Win32/GTK into Smalltalk and abstract them there i.e. do exactly what SWT did in Java. IMO emulation will simply not deliver something that feels native wrt scripting access to the UI, accessibility, bidi text support for all edge cases etc, let alone the visual detail of each GUI (consider GTK theming for example). It's not difficult to do this. The first step is to change the level of native integration/abstraction from the window to a view (to allow native/ST composition). This would immediately allow selective enhancement of VW GUs with native components. Another important choice is to start with OSX, not with Windows or GTK as your baseline. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead. -- Ron Avitzur _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Am 29.11.09 10:43, schrieb Antony Blakey: > I think a better better choice would be to map Cocoa/Win32/GTK into Smalltalk and abstract them there i.e. do exactly what SWT did in Java. IMO emulation will simply not deliver something that feels native wrt scripting access to the UI, accessibility, bidi text support for all edge cases etc, let alone the visual detail of each GUI (consider GTK theming for example). > i second that. Using wxWidgets or Qt doesn't really solve the problem. One could just continue to draw everything in VisualWorks like it is done for decates, with the same effect, instead of letting some third party library do the drawing. What is really needed is a better UI integration in each OS. I'm not sure about Windows or GTK, but on OS X each app shares the same widgets. If you take a simple Text Widget as example: each app has the same spell-checker, the same keyboard-navigation and the same basic context menu for all its Text Widgets. Apps like Thunderbird (which uses some native thingy to emulate its widgets, but doesn't use the real Cocoa Widgets) or VisualWorks or Java-Apps just don't support that and feel different. So it's not just the look in VisualWorks that is different, its especially also the feel that's totally alien. I don't think using Qt or wxWidgets would help fix that only a single bit. I have no idea how to slove that other than with native widgets, but that's hell of a work and not really something easy to do, especially not cross platform. just my 2ct. Karsten -- Karsten Kusche - Dipl. Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Antony Blakey-2
Am 29.11.2009 um 10:43 schrieb Antony Blakey: > Another important choice is to start with OSX, not with Windows or > GTK as your baseline. Indeed. MacOS X can safely be considered the most potent superset of all platforms. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Karsten Kusche
On 29/11/2009, at 8:59 PM, Karsten wrote: > I have no idea how to slove that other than with native widgets, but > that's hell of a work and not really something easy to do, especially > not cross platform. I think the key lesson from SWT is to do as little as possible x-platform abstraction in the VM i.e. the VM should *not* provide a x-platform abstraction to the image. The abstraction should all be done *in* the image. At the very least that would allow a wider range of inputs to the problem, and a sharper toolset being brought to a solution. There is a world of difference between the evolutionary speed/propagation of changes in the VM and the image. VM changes cannot be shared, don't have a distribution mechanism, and aren't open to non-paying customers (these obviously aren't orthogonal points). OTOH, maybe that's already largely possible? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Randy Coulman
Randy Coulman: > However, my concern would be backwards compatibility for existing > customers. This is a killer argument that kills every technology in the long term, because it keeps away new customers. Evolution is mandatory. Organizing evolution is a hard task, though. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Antony Blakey-2
On 29/11/2009, at 8:59 PM, Karsten wrote: > I have no idea how to slove that other than with native widgets, but > that's hell of a work and not really something easy to do, especially > not cross platform. My concrete plan would be to: 1. Provide a significant mapping of Cocoa/Win32/GTK native API into VW, automated obviously using clang/BridgeSupport. 2. Generate an ST model largely mirroring Cocoa, including binding, notifications etc - Cocoa is Objective-C which is already very Smalltalk-ish, and the architecture would work well in Smalltalk. 3. Map the Win32/GTK widgets and facilities into that mapping, extending them in Smalltalk to match Cocoa as necessary. 4. Provide a nib/xib conversion or direct reader facility. If possible, hacking IB to read the ST model to get accessors etc. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The greatest challenge to any thinker is stating the problem in a way that will allow a solution -- Bertrand Russell _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Thomas Sattler
Thomas Sattler escreveu:
> Either would be better than what we have now. Both projects have > already implemented a multi-platform UI solution. Since we, as > Smalltalk developers, march under the banner of "Reuse", let's prove we > mean it. Let's reuse what someone else has already done. > The issues I see with binding instead of integrating (be it Qt or wxWidgets) in Smalltalk is the matter or the mapping of the Smalltalk hierarchy of classes w.r.t. the foreign framework. We already have some of this in Windows when you try to use COM/OLE/ActiveX: since Cincom will not have the resources to write a complete set of documents (with examples from square one) for the Smalltalk implementation, a user of these solutions end up like a translator from one idiom to other. In Windows this usually means getting a VB example and translate it to Smalltalk, in wxWidgets getting a documentation which is C++ oriented (it's happening with wxSqueak http://www.wxsqueak.org/, where the internal doc reader available in the demo image reads these documents). Qt with its complexities added over C++ (IIRC they have a kind of preprocessor to create the C++ classes due their concept of slots and etc.) will make this mapping even more intellectually chalenging. We should also not forget that these new frameworks must be integrated with a GUI creation tool and co-habit the other tools that need to connect the widgets (databases come to mind). . . Last but not the least: the more we lean on those frameworks more Smalltalk gets used as gluing language and less as the main technology for the development of the applications. just my .019999.... -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Antony Blakey-2
I agree that this is better than wxWidgets, but I figured wxWidgets is
easier to produce as a quick project. I wouldn't mind if Cincom were to prove me wrong. ;-) -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Sun, Nov 29, 2009 at 4:43 AM, Antony Blakey <[hidden email]> wrote: > > On 29/11/2009, at 2:29 PM, Carl Gundel wrote: > >> My suggestion was to provide the most basic support for wxWidgets or >> similar mechanism, not to replace the legacy GUI framework. If the >> core is there to support the elementary widgets, events and callbacks >> then the community can add Smalltalk classes for the rest. > > I think a better better choice would be to map Cocoa/Win32/GTK into Smalltalk and abstract them there i.e. do exactly what SWT did in Java. IMO emulation will simply not deliver something that feels native wrt scripting access to the UI, accessibility, bidi text support for all edge cases etc, let alone the visual detail of each GUI (consider GTK theming for example). > > It's not difficult to do this. The first step is to change the level of native integration/abstraction from the window to a view (to allow native/ST composition). This would immediately allow selective enhancement of VW GUs with native components. > > Another important choice is to start with OSX, not with Windows or GTK as your baseline. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead. > -- Ron Avitzur > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Antony Blakey-2
Am 29.11.09 12:47, schrieb Antony Blakey: > 4. Provide a nib/xib conversion or direct reader facility. If possible, hacking IB to read the ST model to get accessors etc. > there's an InterfaceBuilder.framework installed with the devtools that can be used to interact with the IB :-) Karsten -- Karsten Kusche - Dipl. Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 30/11/2009, at 7:28 PM, Karsten wrote: > > Am 29.11.09 12:47, schrieb Antony Blakey: >> 4. Provide a nib/xib conversion or direct reader facility. If possible, hacking IB to read the ST model to get accessors etc. >> > there's an InterfaceBuilder.framework installed with the devtools that can be used to interact with the IB :-) I hadn't/haven't looked, but as my son would say - this could be totally awesome :) Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
If I interpret Sam’s explanation correctly the Widgetry project was doomed in the first place due to chronic
underfunding. Thttp://webmail1f.orange.fr/webmail/fr_FR/write.html#his is revolting as what was probably the best and most easy to modify Smalltalk UI ever made is now sleeping on the shelves. Taken the above however, I don’t really see how Cincom could take up a whole new Wx type integration ? @+Maarten, > Message du 30/11/09 13:34 > De : "Antony Blakey" > A : "VWNC List" > Copie à : > Objet : Re: [vwnc] wxWidgets? Re: Does Cincom give up the Desktop ? > > > > On 30/11/2009, at 7:28 PM, Karsten wrote: > > > > > Am 29.11.09 12:47, schrieb Antony Blakey: > >> 4. Provide a nib/xib conversion or direct reader facility. If possible, hacking IB to read the ST model to get > >> > > there's an InterfaceBuilder.framework installed with the devtools that can be used to interact with the IB :-) > > I hadn't/haven't looked, but as my son would say - this could be totally awesome :) > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > It is no measure of health to be well adjusted to a profoundly sick society. > -- Jiddu Krishnamurti > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
That link takes me to a sales site for Orange?
James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Nov 30, 2009, at 9:25 AM, Maarten MOSTERT wrote: > If I interpret Sam’s explanation correctly the Widgetry project was doomed in the first place due to chronic > underfunding. Thttp://webmail1f.orange.fr/webmail/fr_FR/write.html#his is revolting as what was probably the best > and most easy to modify Smalltalk UI ever made is now > sleeping on the shelves. > > Taken the above however, I don’t really see how Cincom could take up a whole new Wx type integration ? > > @+Maarten, > >> Message du 30/11/09 13:34 >> De : "Antony Blakey" >> A : "VWNC List" >> Copie à : >> Objet : Re: [vwnc] wxWidgets? Re: Does Cincom give up the Desktop ? >> >> >> >> On 30/11/2009, at 7:28 PM, Karsten wrote: >> >>> >>> Am 29.11.09 12:47, schrieb Antony Blakey: >>>> 4. Provide a nib/xib conversion or direct reader facility. If possible, hacking IB to read the ST model to get > accessors etc. >>>> >>> there's an InterfaceBuilder.framework installed with the devtools that can be used to interact with the IB :-) >> >> I hadn't/haven't looked, but as my son would say - this could be totally awesome :) >> >> Antony Blakey >> ------------- >> CTO, Linkuistics Pty Ltd >> Ph: 0438 840 787 >> >> It is no measure of health to be well adjusted to a profoundly sick society. >> -- Jiddu Krishnamurti >> >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Should read:
If I interpret Sam’s explanation correctly the Widgetry project was doomed in the first place due to chronic underfunding. Thhis is revolting as what was probably the best and most easy to modify Smalltalk UI ever made is now sleeping on the shelves. Taken the above however, I don’t really see how Cincom could take up a whole new Wx type integration ? @+Maarten, > Message du 30/11/09 15:51 > De : "James Robertson" > A : "VW NC" > Copie à : > Objet : Re: [vwnc] wxWidgets? Re: Does Cincom give up the Desktop ? > > > That link takes me to a sales site for Orange? > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Nov 30, 2009, at 9:25 AM, Maarten MOSTERT wrote: > > > If I interpret Sam’s explanation correctly the Widgetry project was doomed in the first place due to chronic > > underfunding. Thttp://webmail1f.orange.fr/webmail/fr_FR/write.html#his is revolting as what was probably the > > and most easy to modify Smalltalk UI ever made is now > > sleeping on the shelves. > > > > Taken the above however, I don’t really see how Cincom could take up a whole new Wx type integration ? > > > > @+Maarten, > > > >> Message du 30/11/09 13:34 > >> De : "Antony Blakey" > >> A : "VWNC List" > >> Copie à : > >> Objet : Re: [vwnc] wxWidgets? Re: Does Cincom give up the Desktop ? > >> > >> > >> > >> On 30/11/2009, at 7:28 PM, Karsten wrote: > >> > >>> > >>> Am 29.11.09 12:47, schrieb Antony Blakey: > >>>> 4. Provide a nib/xib conversion or direct reader facility. If possible, hacking IB to read the ST model to > > accessors etc. > >>>> > >>> there's an InterfaceBuilder.framework installed with the devtools that can be used to interact with the IB :- ) > >> > >> I hadn't/haven't looked, but as my son would say - this could be totally awesome :) > >> > >> Antony Blakey > >> ------------- > >> CTO, Linkuistics Pty Ltd > >> Ph: 0438 840 787 > >> > >> It is no measure of health to be well adjusted to a profoundly sick society. > >> -- Jiddu Krishnamurti > >> > >> > >> > >> _______________________________________________ > >> vwnc mailing list > >> [hidden email] > >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >> > >> > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Carl Gundel-2
Thomas Sattler escreveu:
> Either would be better than what we have now. Both projects have already implemented a multi-platform UI solution. Since we, as Smalltalk developers, march under the banner of "Reuse", let's prove we mean it. Let's reuse what someone else has already done. > The issues I see with binding instead of integrating (be it Qt or wxWidgets) in Smalltalk is the matter or the mapping of the Smalltalk hierarchy of classes w.r.t. the foreign framework. We already have some of this in Windows when you try to use COM/OLE/ActiveX: since Cincom will not have the resources to write a complete set of documents (with examples from square one) for the Smalltalk implementation, a user of these solutions end up like a translator from one idiom to other. In Windows this usually means getting a VB example and translate it to Smalltalk, in wxWidgets getting a documentation which is C++ oriented (it's happening with wxSqueak http://www.wxsqueak.org/, where the internal doc reader available in the demo image reads these documents). Qt with its complexities added over C++ (IIRC they have a kind of preprocessor to create the C++ classes due their concept of slots and etc.) will make this mapping even more intellectually chalenging. We should also not forget that these new frameworks must be integrated with a GUI creation tool and co-habit the other tools that need to connect the widgets (databases come to mind). . . Last but not the least: the more we lean on those frameworks more Smalltalk gets used as gluing language and less as the main technology for the development of the applications. just my .019999.... -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |