Smalltalk › Cincom › VisualWorks

MacOS X

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

104 messages Options

123456

Andre Schnoor

Re: MacOS X

Mike Hales wrote:
> Yeah but the point is we want to be able to make apps that look really
> good. They can look awesome and not be native and users will not
> care. I guess my bottom line is this: if it looks awesome it can be
> native or not, and no one will care.

I agree. That's exactly what I am doing. Despite the utterly slow
Quartz/Cocoa drawing which is yet to be improved, it already looks quite
ok. Anti-aliased drawing makes even minimalistic UI designs shine (well,
to a certain extent).

>
> Widgetry extended to use Cairo and Pango seems like the fastest way to
> get that ability. I don't see hacking wrapper to do that, but hacking
> widgetry seems doable. We made a Widgetry CairoCanvas in a couple of
> minutes at Smalltalk Solutions. It fit right into the framework and
> drew with Cairo.

That's great news. But I doubt this will solve the current performance
issues. In order to improve performance on modern graphics platforms,
the VM (and the image) need to implement a different model of
encapsulation for compound drawing actions instead of going through the
"beginDrawing - draw action - endDrawing" cycle for each and every line,
dot, polygon, icon, etc. individually. Can Widgetry do that?

Anyway, I still favor interfacing to the native OS. That's what
operating systems were made for: Provide common resources and services
to all applications in order to make them live together in perfect
harmony. This harmony is disrupted by every product that comes along
with its own (arrogant) notion of user interface.

I'm currently looking at native Mac implementations. It is obvious that
Cocoa provides a modern and comfortable API that offers absolutely
everything an application developer could think off. Why ignore this and
put another layer of megabytes of redundant code on top of that (Cairo)?

With an efficient DLLCC or similar interface, native widgets and a
drawing API can be implemented entirely in the image. Given the current
finalization techniques of VW, the management of OS resources should be
childs play today. Support for a particular platform would be only a
matter of loading the appropriate package.

One of the genuine bad habits of Smalltalk is to always re-invent the
wheels for the sake of a very questionable comfort. The term
cross-platform should NOT mean "keep the platform at a distance". Its
genuine meaning is "bring the platform close to the application" by
using a unified API.

Andre

Alexander Lazarevic'

Re: MacOS X

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Boris Popov schrieb:
> I second that. It would also be nice if Cincom had an experienced
> graphic designer to work on the “new” looks and let engineers do what
> they do best – write code.

Oh, Amen²

Janko Mivšek

Re: MacOS X

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Hi Boris,

> Not “xml configuration + css file + whatnot

I think Cincom can actually learn a lot from experiences designing web
pages, where design is clearly separated from "the code". CSS is
therefore to be considered very seriously even for purely GUI framework
as Widgetry.

Will that way be easier to find designers knowleadgable of CSS, who will
then have easier job to design VW looks and feels?

Best regards
Janko

Boris Popov wrote:

> I second that. It would also be nice if Cincom had an experienced
> graphic designer to work on the “new” looks and let engineers do what
> they do best – write code. Oh, and did I mention “new” looks should be
> easy to create? Not “xml configuration + css file + whatnot” easy, but
> easy in code with clear “look” classes (as few as possible per look)
> that one could a) clone and edit or b) subclass and adjust. So that if
> we were working on a slick new application and got our designer to come
> up with a skin that we would later code into a “look”, I wouldn’t have
> to hack the Widgetry to pieces and create a new artist for every widget
> out there (is that how it works now?).
>
> Cheers!
>
> -Boris

> ------------------------------------------------------------------------
>
> *From:* [hidden email] [mailto:[hidden email]] *On
> Behalf Of *Mike Hales
> *Sent:* Monday, May 28, 2007 2:51 PM
> *To:* Andre Schnoor; vwnc-list
> *Subject:* Re: MacOS X
>
> Yeah but the point is we want to be able to make apps that look really
> good. They can look awesome and not be native and users will not care.
> I guess my bottom line is this: if it looks awesome it can be native or
> not, and no one will care.
>
> Widgetry extended to use Cairo and Pango seems like the fastest way to
> get that ability. I don't see hacking wrapper to do that, but hacking
> widgetry seems doable. We made a Widgetry CairoCanvas in a couple of
> minutes at Smalltalk Solutions. It fit right into the framework and
> drew with Cairo.
>
> Mike
>
> On 5/28/07, *Andre Schnoor* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> They're looking lovely. This kind of L&F however is impossible to create
> with VW currently (although I doubt these number crunching apps are
> typical applications for Smalltalk anyway). One would more likely use ST
> for apps with a complex domain model rather than just pumping streams of
> bytes to the screen or speaker ;-)
>
> Andre

> --
> Mike Hales
> Engineering Manager
> KnowledgeScape
> www.kscape.com <http://www.kscape.com>
>

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Maarten Mostert-2

RE: MacOS X

In reply to this post by Andre Schnoor

Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!

A great looking Widgetry with Cairo Graphics may after all be a good alternative to Dolphins modern looks.

@+Maarten,

> Message du 28/05/07 23:59

> De : "Boris Popov"
> A : "Mike Hales" , "Andre Schnoor" , "vwnc-list"
> Copie à :
> Objet : RE: MacOS X
>
>

I second that. It would also be nice if Cincom had an experienced graphic designer to work on the “new” looks and let engineers do what they do best – write code. Oh, and did I mention “new” looks should be easy to create? Not “xml configuration + css file + whatnot” easy, but easy in code with clear “look” classes (as few as possible per look) that one could a) clone and edit or b) subclass and adjust. So that if we were working on a slick new application and got our designer to come up with a skin that we would later code into a “look”, I wouldn’t have to hack the Widgetry to pieces and create a new artist for every widget out there (is that how it works now?).

Cheers!

> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Mike Hales
> Sent: Monday, May 28, 2007 2:51 PM
> To: Andre Schnoor; vwnc-list
> Subject: Re: MacOS X

Yeah but the point is we want to be able to make apps that look really good. They can look awesome and not be native and users will not care. I guess my bottom line is this: if it looks awesome it can be native or not, and no one will care.
>
> Widgetry extended to use Cairo and Pango seems like the fastest way to get that ability. I don't see hacking wrapper to do that, but hacking widgetry seems doable. We made a Widgetry CairoCanvas in a couple of minutes at Smalltalk Solutions. It fit right into the framework and drew with Cairo.
>
> Mike

On 5/28/07, Andre Schnoor <[hidden email]> wrote:

>
> They're looking lovely. This kind of L&F however is impossible to create with VW currently (although I doubt these number crunching apps are typical applications for Smalltalk anyway). One would more likely use ST for apps with a complex domain model rather than just pumping streams of bytes to the screen or speaker ;-)
>
>
> Andre

>

> --
> Mike Hales
> Engineering Manager
> KnowledgeScape
> www.kscape.com

Mike Hales

Re: MacOS X

In reply to this post by Mike Hales

On 5/28/07, Travis Griggs <[hidden email]> wrote:

Memorial day work warrior, huh? :)

Just curious why you feel Widgetry is so much better to do this with? The GC code is completely agnostic between the two. Not that I'm anti-wrapper or pro. Or the same for widgetry, I just want to see goodness given credit where due.

I'm in Peru, so memorial day doesn't really apply, although I'd rather be home boating. Honestly I'm biased towards Widgetry because that is what I'm using going forward. I don't care about backwards compatibility with existing projects since I'm dumping my existing gui and moving forward with a new one. That said, I think Widgetry offers a better framework for a more modern GUI because:

It's trivial to build guis programatically, therefore change them on the fly programtically also. This is not so easy in wrapper but important for a really nice, dynamic and powerful interface.

It uses announcements, which are really nice to work with and powerful because they are real objects.

It has Grid. This is infinitely better than the old options and can have any other widget in it, including Forms.

Drag and drop is way easier.

Keyboard handling is really easy by just passing the keyboard hook block to the pane. If you want to process it do it and return nil if not pass it on. This is so nice.

The code in Widgetry is well commented, even without docs it's easy to grok and to extend.

To me, all if this adds up and makes Widgetry the best place to focus. Also, since Widgetry is touted as the way forward for VW, the effort should go there. If Widetry is not the way forward, what in the world has been going on at Cincom for the last 4 years? If I have to make any significant effort in making a really great gui, I'm not going to do it for a framework whose days are numbered. Isn't the plan to have Widgtry-ified tools and move away from Wrapper? Resources are always limited, so why not invest those limited resources in the future rather than the past. Sure everybody whines, but how many OSX users are now sad that Apple made a clean break and pushed to a superior product but left a few behind? Not many.

This is my direction, others will undoubtedly follow a different path.

--
Mike Hales
Engineering Manager
KnowledgeScape
www.kscape.com

Carl Gundel

Native widgets Re: MacOS X

In reply to this post by Maarten Mostert-2

...... Original Message .......
On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
<[hidden email]> wrote:
>Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
>A great looking Widgetry with Cairo Graphics may after all be a good
alternative to Dolphins modern looks.

Not to say that Cairo or some other way to draw graphics more easily and
attractively would not be great, but ultimately we need native widgets.
There is simply no way for an emulated look and feel to keep up with the
changes that happen continously. Consider Vista. How long would it take
to craft a new L&F for it? Would it look acceptable, and would it be
obsolete as soon as it appears?

-Carl Gundel
http://www.libertybasic.com

Stefan Schmiedl

Re: Native widgets Re: MacOS X

On Tue, 29 May 2007 10:40:18 -0400
Carl Gundel <[hidden email]> wrote:

> Not to say that Cairo or some other way to draw graphics more easily
> and attractively would not be great, but ultimately we need native
> widgets. There is simply no way for an emulated look and feel to keep
> up with the changes that happen continously. Consider Vista.

Clients of mine have considered Vista and Office 2007 and decided not
to use it as long as possible. *Because* the look and feel changed so
dramatically that they felt lost. Many of the people working there are
*happy* with a clean and simple looking GUI that does not change every
two years. They actually value function over form.

So I'm quite happy with emulated widgets. But that might be just me.
s.
--
Stefan Schmiedl

OCIT

Re: Native widgets Re: MacOS X

In reply to this post by Carl Gundel

I know that I'm way in the minority but I think that support for native
widgets verges on suicidal. Unless things have changed native widget
support would impose huge maintanence burdens on an engineering staff that
is already stretched. I really prefer the "skinable" philosophy which
seems to be pretty popular i.e. look at WinAmp and others, not sure if
they are relying on native widgets but the point is that users tend to
want to customize their apps look i.e. care less if it looks like Windows
, MAC. KDE, Gnome or the other million Linux widget sets, well maybe not
millions ....

Carl, I would think that with something like your app i.e. an IDE, that
your users would be into the skinnable thing.

I'm actually in favor of leveraging a cross-platform external graphics
framework and actually would hope that one day the same would be done for
sound.

Cairo sounds good.

-Charles

On Tue, 29 May 2007 10:40:18 -0400, Carl Gundel <[hidden email]>
wrote:

> ...... Original Message .......
> On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
> <[hidden email]> wrote:
>> Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> A great looking Widgetry with Cairo Graphics may after all be a good
> alternative to Dolphins modern looks.
>
> Not to say that Cairo or some other way to draw graphics more easily and
> attractively would not be great, but ultimately we need native widgets.
> There is simply no way for an emulated look and feel to keep up with the
> changes that happen continously. Consider Vista. How long would it take
> to craft a new L&F for it? Would it look acceptable, and would it be
> obsolete as soon as it appears?
>
> -Carl Gundel
> http://www.libertybasic.com
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Eliot Miranda-2

Re: Native widgets Re: MacOS X

On 5/29/07, Charles A. Monteiro <[hidden email]> wrote:

I know that I'm way in the minority but I think that support for native
widgets verges on suicidal. Unless things have changed native widget
support would impose huge maintanence burdens on an engineering staff that
is already stretched.

Can you expand on this Charles? Why do you think an interface to native widgets would increase maintennance? I think the opposite (no need to put effort into aping ever-changing looks) but I'm interested in your reasons for thinking the opposite...

I really prefer the "skinable" philosophy which
seems to be pretty popular i.e. look at WinAmp and others, not sure if
they are relying on native widgets but the point is that users tend to
want to customize their apps look i.e. care less if it looks like Windows
, MAC. KDE, Gnome or the other million Linux widget sets, well maybe not
millions ....

Carl, I would think that with something like your app i.e. an IDE, that
your users would be into the skinnable thing.

I'm actually in favor of leveraging a cross-platform external graphics
framework and actually would hope that one day the same would be done for
sound.

Cairo sounds good.

-Charles

On Tue, 29 May 2007 10:40:18 -0400, Carl Gundel <[hidden email]>
wrote:

> ...... Original Message .......
> On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
> <[hidden email]> wrote:
>> Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> A great looking Widgetry with Cairo Graphics may after all be a good
> alternative to Dolphins modern looks.
>
> Not to say that Cairo or some other way to draw graphics more easily and
> attractively would not be great, but ultimately we need native widgets.
> There is simply no way for an emulated look and feel to keep up with the
> changes that happen continously. Consider Vista. How long would it take
> to craft a new L&F for it? Would it look acceptable, and would it be
> obsolete as soon as it appears?
>
> -Carl Gundel
> http://www.libertybasic.com
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Travis Griggs-3

Re: MacOS X

In reply to this post by Andre Schnoor

On May 29, 2007, at 0:17, Andre Schnoor wrote:

Mike Hales wrote:

Yeah but the point is we want to be able to make apps that look really good. They can look awesome and not be native and users will not care. I guess my bottom line is this: if it looks awesome it can be native or not, and no one will care.

I agree. That's exactly what I am doing. Despite the utterly slow Quartz/Cocoa drawing which is yet to be improved, it already looks quite ok. Anti-aliased drawing makes even minimalistic UI designs shine (well, to a certain extent).

Widgetry extended to use Cairo and Pango seems like the fastest way to get that ability. I don't see hacking wrapper to do that, but hacking widgetry seems doable. We made a Widgetry CairoCanvas in a couple of minutes at Smalltalk Solutions. It fit right into the framework and drew with Cairo.

That's great news. But I doubt this will solve the current performance issues. In order to improve performance on modern graphics platforms, the VM (and the image) need to implement a different model of encapsulation for compound drawing actions instead of going through the "beginDrawing - draw action - endDrawing" cycle for each and every line, dot, polygon, icon, etc. individually. Can Widgetry do that?

Exactly! You've said very nicely what I've been edging around in the parallel discussion about looks. "Cool drawing" isn't done with the VW API on a "better engine." It's just done differently. Lots of similarities, but things shift.

Anyway, I still favor interfacing to the native OS. That's what operating systems were made for: Provide common resources and services to all applications in order to make them live together in perfect harmony. This harmony is disrupted by every product that comes along with its own (arrogant) notion of user interface.

I'm currently looking at native Mac implementations. It is obvious that Cocoa provides a modern and comfortable API that offers absolutely everything an application developer could think off. Why ignore this and put another layer of megabytes of redundant code on top of that (Cairo)?

One of the nice things about the Cairo API is that it is pretty much just a pass through to CGContextRef APIs.

Travis Griggs

Objologist

"Only one thing is impossible for God: to find any sense in any copyright law on the planet." - Mark Twain

OCIT

Re: Native widgets Re: MacOS X

In reply to this post by Eliot Miranda-2

Eliot:

If you feel that there are no issues now then that makes me happy :), yet
I wonder what the initial development effort will be to have native
widgets available for at least the major VW platforms i.e. Win, Mac, and
Linux which I suppose that means support for KDE and Gnome? Again, there
is always a trade-off, time spent on this is time not spent on something
else, unless one has infinite resources.

With regards to dev/maintenance issues, there has been or at least was a
reason why emulated widgets was the most manegeable way of going for VW in
earlier days perhaps things have changed but you would of course know much
better than I would.

Java had an awful time at native widgets for a while, not sure that the
current state of affairs is there now. I also remember,and it has been a
while, Eclipse having a difficult time with SWT in maintaining
cross-platform compatability. Specifically, their Linux implementation was
quite behind their Windows implementation and it was sloooow. I guess if
one did not care about cross-platform compatability then one just needed
to live with the pain but if you did you were hosed.

Anyhow, as is always the case, in comes to what value will native widgets
bring in relations to its cost in time spent and in time not spent doing
something else. Obviously, if the cost is not that great , hey, fantastic
but I have waited years to get fixes and features that could have been
done a while back.

Again, I suspect that native widgets is a popular thing so most will thing
that the value added by far outweights the cost. In our case, our apps
look good enough, we make the sell because of what they do. If I was
selling consumer oriented stuff I may be singing a different tune, unless
I could give them skins :)

later

-Charles

On Tue, 29 May 2007 13:37:34 -0400, Eliot Miranda
<[hidden email]> wrote:

> On 5/29/07, Charles A. Monteiro <[hidden email]> wrote:
>>
>> I know that I'm way in the minority but I think that support for native
>> widgets verges on suicidal. Unless things have changed native widget
>> support would impose huge maintanence burdens on an engineering staff
>> that
>> is already stretched.
>
>
> Can you expand on this Charles? Why do you think an interface to native
> widgets would increase maintennance? I think the opposite (no need to
> put
> effort into aping ever-changing looks) but I'm interested in your
> reasons
> for thinking the opposite...
>
>
> I really prefer the "skinable" philosophy which
>> seems to be pretty popular i.e. look at WinAmp and others, not sure if
>> they are relying on native widgets but the point is that users tend to
>> want to customize their apps look i.e. care less if it looks like
>> Windows
>> , MAC. KDE, Gnome or the other million Linux widget sets, well maybe not
>> millions ....
>>
>> Carl, I would think that with something like your app i.e. an IDE, that
>> your users would be into the skinnable thing.
>>
>> I'm actually in favor of leveraging a cross-platform external graphics
>> framework and actually would hope that one day the same would be done
>> for
>> sound.
>>
>> Cairo sounds good.
>>
>> -Charles
>>
>>
>> On Tue, 29 May 2007 10:40:18 -0400, Carl Gundel <[hidden email]>
>> wrote:
>>
>> > ...... Original Message .......
>> > On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
>> > <[hidden email]> wrote:
>> >> Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> >> A great looking Widgetry with Cairo Graphics may after all be a good
>> > alternative to Dolphins modern looks.
>> >
>> > Not to say that Cairo or some other way to draw graphics more easily
>> and
>> > attractively would not be great, but ultimately we need native
>> widgets.
>> > There is simply no way for an emulated look and feel to keep up with
>> the
>> > changes that happen continously. Consider Vista. How long would it
>> take
>> > to craft a new L&F for it? Would it look acceptable, and would it be
>> > obsolete as soon as it appears?
>> >
>> > -Carl Gundel
>> > http://www.libertybasic.com
>> >
>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
>>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Boris Popov, DeepCove Labs (SNN)

RE: Native widgets Re: MacOS X

So what happens when widget X on platform Y has a unique property Z and
people would like it exposed? Are we going to end up with the lowest
common denominator UI? If that's the case, I'd rather have emulated UI,
but one that can be extended across all platforms.

No?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Charles A. Monteiro [mailto:[hidden email]]
> Sent: Tuesday, May 29, 2007 11:07 AM
> To: Eliot Miranda
> Cc: [hidden email]
> Subject: Re: Native widgets Re: MacOS X
>
> Eliot:
>
> If you feel that there are no issues now then that makes me happy :),

yet
> I wonder what the initial development effort will be to have native
> widgets available for at least the major VW platforms i.e. Win, Mac,
and
> Linux which I suppose that means support for KDE and Gnome? Again,
there
> is always a trade-off, time spent on this is time not spent on
something
> else, unless one has infinite resources.
>
> With regards to dev/maintenance issues, there has been or at least was
a
> reason why emulated widgets was the most manegeable way of going for
VW in
> earlier days perhaps things have changed but you would of course know
much
> better than I would.
>
> Java had an awful time at native widgets for a while, not sure that
the
> current state of affairs is there now. I also remember,and it has been
a
> while, Eclipse having a difficult time with SWT in maintaining
> cross-platform compatability. Specifically, their Linux implementation
was
> quite behind their Windows implementation and it was sloooow. I guess
if
> one did not care about cross-platform compatability then one just
needed
> to live with the pain but if you did you were hosed.
>
> Anyhow, as is always the case, in comes to what value will native
widgets
> bring in relations to its cost in time spent and in time not spent
doing
> something else. Obviously, if the cost is not that great , hey,
fantastic
> but I have waited years to get fixes and features that could have been
> done a while back.
>
> Again, I suspect that native widgets is a popular thing so most will
thing
> that the value added by far outweights the cost. In our case, our apps
> look good enough, we make the sell because of what they do. If I was
> selling consumer oriented stuff I may be singing a different tune,
unless

> I could give them skins :)
>
> later
>
> -Charles
>
>
> On Tue, 29 May 2007 13:37:34 -0400, Eliot Miranda
> <[hidden email]> wrote:
>
> > On 5/29/07, Charles A. Monteiro <[hidden email]> wrote:
> >>
> >> I know that I'm way in the minority but I think that support for

native
> >> widgets verges on suicidal. Unless things have changed native
widget
> >> support would impose huge maintanence burdens on an engineering
staff
> >> that
> >> is already stretched.
> >
> >
> > Can you expand on this Charles? Why do you think an interface to
> native
> > widgets would increase maintennance? I think the opposite (no need
to
> > put
> > effort into aping ever-changing looks) but I'm interested in your
> > reasons
> > for thinking the opposite...
> >
> >
> > I really prefer the "skinable" philosophy which
> >> seems to be pretty popular i.e. look at WinAmp and others, not sure
if
> >> they are relying on native widgets but the point is that users tend
to
> >> want to customize their apps look i.e. care less if it looks like
> >> Windows
> >> , MAC. KDE, Gnome or the other million Linux widget sets, well
maybe
> not
> >> millions ....
> >>
> >> Carl, I would think that with something like your app i.e. an IDE,
that
> >> your users would be into the skinnable thing.
> >>
> >> I'm actually in favor of leveraging a cross-platform external
graphics
> >> framework and actually would hope that one day the same would be
done

> >> for
> >> sound.
> >>
> >> Cairo sounds good.
> >>
> >> -Charles
> >>
> >>
> >> On Tue, 29 May 2007 10:40:18 -0400, Carl Gundel
> <[hidden email]>
> >> wrote:
> >>
> >> > ...... Original Message .......
> >> > On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
> >> > <[hidden email]> wrote:
> >> >> Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >> >> A great looking Widgetry with Cairo Graphics may after all be a

good
> >> > alternative to Dolphins modern looks.
> >> >
> >> > Not to say that Cairo or some other way to draw graphics more
easily
> >> and
> >> > attractively would not be great, but ultimately we need native
> >> widgets.
> >> > There is simply no way for an emulated look and feel to keep up
with
> >> the
> >> > changes that happen continously. Consider Vista. How long would
it
> >> take
> >> > to craft a new L&F for it? Would it look acceptable, and would
it be

> >> > obsolete as soon as it appears?
> >> >
> >> > -Carl Gundel
> >> > http://www.libertybasic.com
> >> >
> >>
> >>
> >>
> >> --
> >> Using Opera's revolutionary e-mail client:

http://www.opera.com/mail/
> >>
> >>
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Eliot Miranda-2

Re: Native widgets Re: MacOS X

On 5/29/07, Boris Popov <[hidden email]> wrote:

So what happens when widget X on platform Y has a unique property Z and
people would like it exposed? Are we going to end up with the lowest
common denominator UI? If that's the case, I'd rather have emulated UI,
but one that can be extended across all platforms.

The natural architecture would be to provide a fall-back implementation above the lowest common denominator, which may lose fidelity (e.g. no anti-aliasing or no transparency), but to override this with the platform's faclities where they exist, right?

Remember that right now the emulated UI exists above the native UI, its just that access to the native UI is smothered by the VM. Emulated and nativite interfaces can coexist. Right?

No?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Charles A. Monteiro [mailto:[hidden email]]
> Sent: Tuesday, May 29, 2007 11:07 AM
> To: Eliot Miranda
> Cc: [hidden email]
> Subject: Re: Native widgets Re: MacOS X
>
> Eliot:
>
> If you feel that there are no issues now then that makes me happy :),
yet
> I wonder what the initial development effort will be to have native
> widgets available for at least the major VW platforms i.e. Win, Mac,
and
> Linux which I suppose that means support for KDE and Gnome? Again,
there
> is always a trade-off, time spent on this is time not spent on
something
> else, unless one has infinite resources.
>
> With regards to dev/maintenance issues, there has been or at least was
a
> reason why emulated widgets was the most manegeable way of going for
VW in
> earlier days perhaps things have changed but you would of course know
much
> better than I would.
>
> Java had an awful time at native widgets for a while, not sure that
the
> current state of affairs is there now. I also remember,and it has been
a
> while,  Eclipse having a difficult time with SWT in maintaining
> cross-platform compatability. Specifically, their Linux implementation
was
> quite behind their Windows implementation and it was sloooow. I guess
if
> one did not care about cross-platform compatability then one just
needed
> to live with the pain but if you did you were hosed.
>
> Anyhow, as is always the case, in comes to what value will native
widgets
> bring in relations to its cost in time spent and in time not spent
doing
> something else. Obviously, if the cost is not that great , hey,
fantastic
> but I have waited years to get fixes and features that could have been
> done a while back.
>
> Again, I suspect that native widgets is a popular thing so most will
thing
> that the value added by far outweights the cost. In our case, our apps
> look good enough, we make the sell because of what they do. If I was
> selling consumer oriented stuff I may be singing a different tune,
unless

> I could give them skins :)
>
> later
>
> -Charles
>
>
> On Tue, 29 May 2007 13:37:34 -0400, Eliot Miranda
> <[hidden email]> wrote:
>
> > On 5/29/07, Charles A. Monteiro <[hidden email]> wrote:
> >>
> >> I know that I'm way in the minority but I think that support for
native
> >> widgets verges on suicidal. Unless things have changed native
widget
> >> support would impose huge maintanence burdens on an engineering
staff
> >> that
> >> is already stretched.
> >
> >
> > Can you expand on this Charles?  Why do you think an interface  to
> native
> > widgets would increase maintennance?  I think the opposite (no need
to
> > put
> > effort into aping ever-changing looks)  but I'm interested in your
> > reasons
> > for thinking the opposite...
> >
> >
> > I really prefer the "skinable" philosophy which
> >> seems to be pretty popular i.e. look at WinAmp and others, not sure
if
> >> they are relying on native widgets but the point is that users tend
to
> >> want to customize their apps look i.e. care less if it looks like
> >> Windows
> >> , MAC. KDE, Gnome or the other million Linux widget sets, well
maybe
> not
> >> millions ....
> >>
> >> Carl, I would think that with something like your app i.e. an IDE,
that
> >> your users would be into the skinnable thing.
> >>
> >> I'm actually in favor of leveraging a cross-platform external
graphics
> >> framework and actually would hope that one day the same would be
done

> >> for
> >> sound.
> >>
> >> Cairo sounds good.
> >>
> >> -Charles
> >>
> >>
> >> On Tue, 29 May 2007 10:40:18 -0400, Carl Gundel
> <[hidden email]>
> >> wrote:
> >>
> >> > ...... Original Message .......
> >> > On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
> >> > <[hidden email]> wrote:
> >> >> Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >> >> A great looking Widgetry with Cairo Graphics may after all be a
good
> >> > alternative to Dolphins modern looks.
> >> >
> >> > Not to say that Cairo or some other way to draw graphics more
easily
> >> and
> >> > attractively would not be great, but ultimately we need native
> >> widgets.
> >> > There is simply no way for an emulated look and feel to keep up
with
> >> the
> >> > changes that happen continously.  Consider Vista.  How long would
it
> >> take
> >> > to craft a new L&F for it?  Would it look acceptable, and would
it be

> >> > obsolete as soon as it appears?
> >> >
> >> > -Carl Gundel
> >> > http://www.libertybasic.com
> >> >
> >>
> >>
> >>
> >> --
> >> Using Opera's revolutionary e-mail client:
http://www.opera.com/mail/
> >>
> >>
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Stefan Schmiedl

Re: Native widgets Re: MacOS X

In reply to this post by Boris Popov, DeepCove Labs (SNN)

On Tue, 29 May 2007 11:28:59 -0700
"Boris Popov" <[hidden email]> wrote:

> So what happens when widget X on platform Y has a unique property Z
> and people would like it exposed? Are we going to end up with the
> lowest common denominator UI? If that's the case, I'd rather have
> emulated UI, but one that can be extended across all platforms.

This works the other way around, too. I found the "just type"
approach e.g. in the SB's package tree to be quite nice (once I had my
keyboard settings fixed). This is actually *more* than I am used to
from "native" tree controls.

s.

Boris Popov, DeepCove Labs (SNN)

RE: Native widgets Re: MacOS X

Exactly, then you get into situations where you'd like a custom widget
stuck alongside a bunch of native widgets and suddenly you either have
to emulate the look across X target platforms (which will never match
native widgets right next to it exactly anyway) or live with the fact
that it's different (yuk). I would personally much rather see skins
(professionally done) than native widgets; you *can* have good looking
application that aren't native. I'm not sold on the whole native widgets
idea at all and would much rather see Pollock completed and working
(tools included), it all comes down to resource management at some
point...

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Stefan Schmiedl [mailto:[hidden email]]
> Sent: Tuesday, May 29, 2007 11:48 AM
> To: [hidden email]
> Subject: Re: Native widgets Re: MacOS X
>
> On Tue, 29 May 2007 11:28:59 -0700
> "Boris Popov" <[hidden email]> wrote:
>
> > So what happens when widget X on platform Y has a unique property Z
> > and people would like it exposed? Are we going to end up with the
> > lowest common denominator UI? If that's the case, I'd rather have
> > emulated UI, but one that can be extended across all platforms.
>
> This works the other way around, too. I found the "just type"
> approach e.g. in the SB's package tree to be quite nice (once I had my
> keyboard settings fixed). This is actually *more* than I am used to
> from "native" tree controls.
>
> s.

Eliot Miranda-2

Re: Native widgets Re: MacOS X

In reply to this post by OCIT

On 5/29/07, Charles A. Monteiro <[hidden email]> wrote:

Eliot:

If you feel that there are no issues now then that makes me happy :), yet
I wonder what the initial development effort will be to have native
widgets available for at least the major VW platforms i.e. Win, Mac, and
Linux which I suppose that means support for KDE and Gnome? Again, there
is always a trade-off, time spent on this is time not spent on something
else, unless one has infinite resources.

With regards to dev/maintenance issues, there has been or at least was a
reason why emulated widgets was the most manegeable way of going for VW in
earlier days perhaps things have changed but you would of course know much
better than I would.

I think its because development of the Chameleon gui (what VW's GUI used to be caled) preceeded the development of the FFI. When Chamelon was done the VM only provided user primitives which had very poor callback facilites. But when Van Gogh was worked on DLLCC had been developed and hence it was practicable to access the platform GUI directly through DLLCC.

But look, if there is a decent FFI (and DLLCC isn't yet quite decent; its slowish - less important on today's superfast machines, but still - and its imperfect, especially in I18N string handling) and its really true that Smalltalk is more productive than C (something I think is proven) then it has to be more efficient to implement the GUI/platform GUI interface in Smalltalk.

Java had an awful time at native widgets for a while, not sure that the
current state of affairs is there now. I also remember,and it has been a
while, Eclipse having a difficult time with SWT in maintaining
cross-platform compatability. Specifically, their Linux implementation was
quite behind their Windows implementation and it was sloooow. I guess if
one did not care about cross-platform compatability then one just needed
to live with the pain but if you did you were hosed.

But what exactly were the problems? One advantage VW has is an existing cross-platform framework that works. Its far easier to reengineer something functional than to do a green field design. And there are several other advantages VW has over Java, real-world speed, footprint, IDE maturity.

But all this is academic. The essential problem is opportunity cost. While implementing a native GUI might be a very good thing in the long term doping it will mean not doing something else that might be more important. The tragedy is that if one isn't willing to invest in infrastructure then gradually the foundations get poorer and poorer and have to support ever more poorly implemented superstructure (rthe quality of the foundations determine how well one can implement above it).

But enough already.

Anyhow, as is always the case, in comes to what value will native widgets
bring in relations to its cost in time spent and in time not spent doing
something else. Obviously, if the cost is not that great , hey, fantastic
but I have waited years to get fixes and features that could have been
done a while back.

Again, I suspect that native widgets is a popular thing so most will thing
that the value added by far outweights the cost. In our case, our apps
look good enough, we make the sell because of what they do. If I was
selling consumer oriented stuff I may be singing a different tune, unless
I could give them skins :)

later

-Charles

On Tue, 29 May 2007 13:37:34 -0400, Eliot Miranda
<[hidden email]> wrote:

> On 5/29/07, Charles A. Monteiro <[hidden email]> wrote:
>>
>> I know that I'm way in the minority but I think that support for native
>> widgets verges on suicidal. Unless things have changed native widget
>> support would impose huge maintanence burdens on an engineering staff
>> that
>> is already stretched.
>
>
> Can you expand on this Charles?  Why do you think an interface  to native
> widgets would increase maintennance?  I think the opposite (no need to
> put
> effort into aping ever-changing looks)  but I'm interested in your
> reasons
> for thinking the opposite...
>
>
> I really prefer the "skinable" philosophy which
>> seems to be pretty popular i.e. look at WinAmp and others, not sure if
>> they are relying on native widgets but the point is that users tend to

>> want to customize their apps look i.e. care less if it looks like
>> Windows
>> , MAC. KDE, Gnome or the other million Linux widget sets, well maybe not
>> millions ....
>>
>> Carl, I would think that with something like your app i.e. an IDE, that
>> your users would be into the skinnable thing.
>>
>> I'm actually in favor of leveraging a cross-platform external graphics
>> framework and actually would hope that one day the same would be done
>> for
>> sound.
>>
>> Cairo sounds good.
>>
>> -Charles
>>
>>
>> On Tue, 29 May 2007 10:40:18 -0400, Carl Gundel <[hidden email]>

>> wrote:
>>
>> > ...... Original Message .......
>> > On Tue, 29 May 2007 13:20:03 +0200 (CEST) Maarten MOSTERT
>> > <[hidden email]> wrote:
>> >> Oh yes please !!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> >> A great looking Widgetry with Cairo Graphics may after all be a good
>> > alternative to Dolphins modern looks.
>> >
>> > Not to say that Cairo or some other way to draw graphics more easily
>> and
>> > attractively would not be great, but ultimately we need native
>> widgets.
>> > There is simply no way for an emulated look and feel to keep up with
>> the
>> > changes that happen continously.  Consider Vista.  How long would it
>> take
>> > to craft a new L&F for it?  Would it look acceptable, and would it be
>> > obsolete as soon as it appears?
>> >
>> > -Carl Gundel
>> > http://www.libertybasic.com
>> >
>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
>>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Carl Gundel

Re: Native widgets Re: MacOS X

In reply to this post by Eliot Miranda-2

From: "Eliot Miranda" <[hidden email]>
> Remember that right now the emulated UI exists above the native UI, its
> just
> that access to the native UI is smothered by the VM. Emulated and
> nativite
> interfaces can coexist. Right?

Yes. My VisualSmalltalk based version of Liberty BASIC uses mostly native
widgets, but also has an emulated TextPane widget. This is nice to have
because I was able to add syntax coloring, autoindenting, etc. in Smalltalk.
So it is good to have both native and emulated widgets.

-Carl Gundel
http://www.libertybasic.com

Stefan Schmiedl

Re: Native widgets Re: MacOS X

In reply to this post by Boris Popov, DeepCove Labs (SNN)

On Tue, 29 May 2007 11:54:43 -0700
"Boris Popov" <[hidden email]> wrote:

> Exactly, then you get into situations where you'd like a custom widget
> stuck alongside a bunch of native widgets and suddenly you either have
> to emulate the look across X target platforms (which will never match
> native widgets right next to it exactly anyway) or live with the fact
> that it's different (yuk).

hm? Maybe I read you wrong, but what you describe sounds more like
a "either do it with a (slightly) ugly interface or don't do it at all"
decision to me.

I have a client with a simple no-AJAX-in-the-old-days-buddy intranet
application. People are cursing the dropdown fields in Internet
Explorer, because the look like, but don't behave like the comboboxes
they are used to from working with Access frontends all day. I am
looking forward to change this to some AJAX-based autocompleter, which
will not look "native" to the IE experience, but be a measurable
improvement to the speed they can work with this thing.

Function wins over Form for my serious users.

> I would personally much rather see skins
> (professionally done) than native widgets; you *can* have good looking
> application that aren't native.

No need to dispute that :-)

s.

Boris Popov, DeepCove Labs (SNN)

RE: Native widgets Re: MacOS X

So this (attached) would look okay, you think? If you are serious about
UI, mixing native and non-native wouldn't fly most of the time, in which
case Cincom would either have to drop emulation and do it all native or
end up supporting both, which isn't "less work going forward" in my book
unless there's some magic piece that I'm missing.

By the way, input field with auto-completion wired into it would still
look like any other input field on the same page, since you're replacing
a native combo-box with a native input field that simply behaves better
:)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Stefan Schmiedl [mailto:[hidden email]]
> Sent: Tuesday, May 29, 2007 12:31 PM
> To: [hidden email]
> Subject: Re: Native widgets Re: MacOS X
>
> On Tue, 29 May 2007 11:54:43 -0700
> "Boris Popov" <[hidden email]> wrote:
>
> > Exactly, then you get into situations where you'd like a custom

widget
> > stuck alongside a bunch of native widgets and suddenly you either

have
> > to emulate the look across X target platforms (which will never
match
> > native widgets right next to it exactly anyway) or live with the
fact
> > that it's different (yuk).
>
> hm? Maybe I read you wrong, but what you describe sounds more like
> a "either do it with a (slightly) ugly interface or don't do it at
all"

> decision to me.
>
> I have a client with a simple no-AJAX-in-the-old-days-buddy intranet
> application. People are cursing the dropdown fields in Internet
> Explorer, because the look like, but don't behave like the comboboxes
> they are used to from working with Access frontends all day. I am
> looking forward to change this to some AJAX-based autocompleter, which
> will not look "native" to the IE experience, but be a measurable
> improvement to the speed they can work with this thing.
>
> Function wins over Form for my serious users.
>
> > I would personally much rather see skins
> > (professionally done) than native widgets; you *can* have good

looking
> > application that aren't native.
>
> No need to dispute that :-)
>
> s.

sample.jpg (56K) Download Attachment

Stefan Schmiedl

Re: Native widgets Re: MacOS X

On Tue, 29 May 2007 12:44:28 -0700
"Boris Popov" <[hidden email]> wrote:

> So this (attached) would look okay, you think?

Let's just say, I knew why I put "slightly" in parentheses .-)
If the text box beneath the list provided *essential* functionality
that could not be had otherwise, I'd leave the decision to the users.
I might be sitting in a different tree, since I'm mostly developing
applications for clients who want to get things done as quickly as
possible and are willing to "overlook" some scars.

> By the way, input field with auto-completion wired into it would still
> look like any other input field on the same page, since you're
> replacing a native combo-box with a native input field that simply
> behaves better :)

I will be replacing a native ListBox with a non-native ComboBox. The
simplistic ListBox does not take well to typing in more than one
letter, so you're out of luck if the name you're looking for is right
in the middle of a large block with the same leading characters.

s.

123456