Mailing List Archive

In article <371E964F.C531C2A@istar.ca>, eugened@istar.ca spoke thusly:
> For programmers using languages other than Tcl.
>
> I recently "discovered" the latest stable version of Tcl/Tk (8.05) and
> must say that was quite impressed by the simplicity and ease of use of
> Tk.
>
> But I also found that while older versions of Tk were using lightweight
> components (Some Java terminology :) the latest version is using native
> components for things like scrollbars and buttons.
>
> I don't want to say that this is bad for Tcl users but what about all
> the other languages that use Tk? Isn't writting multiplatform GUI harder
> using native components....

Tk does all the hard work, depending on which platform it's compiled for.
The gui programmer makes the same calls in either case.
--
Don Groves (groves_acm_org)
Replace underscores to get my email address

> I don't want to say that this is bad for Tcl users but what about all
> the other languages that use Tk? Isn't writting multiplatform GUI
harder
> using native components.

I don't think that implementing all widgets using custom code on all
platforms is 'lightweight' at
all. The issues about lightweight components for me are performance and
cross-platform
compatibility. By using native components, Tk has moved closer to this
goal. Yes, the differences in
look (and to some extent, feel) of components, when usig native widgets,
can be every-so-slightly
compromised - however, in the case of Tk, I don't find this a major
worry, irrespective of the
manner by which I access Tk (Tcl, Perl, C etc).

> I think Java made big step forward in
> abandoning the native components and using lightweight > ones in
Swing.

I've got a lot good words to say about Swing, but I don't think that
it's too smart to emulate the
<insert os/toolkit> look'n'feel on the same os/toolkit. The results are
typically a poor imitation
and always slow. It reminds me of the days when I used ParcPlace's
Smalltalk - very bad!

Fuzz

In article <371E964F.C531C2A@istar.ca>,
Eugene Dragoev <eugened@istar.ca> wrote:
> Is there going to be any Tk implementation that will continue using
> lightweight components?

No current Tk implementation uses lightweight components. All are
heavy (which actually merely means that they have their own window
each.) One of the things that might come out of the TkGS work at some
point may be lightweight components. There are other issues being
resolved there first though...

On the subject of what you thought lightweight components were: There
was a substantial discussion on this matter long ago (at the start of
the 8.0 cycle) and the decision was reached that what many people
actually wanted was not components that looked the same on all
platforms (they had that before and didn't like it) but rather
components that fitted in on the platform that they were being run
under at the time. Like that, an application that looks like it
belongs when running under Solaris/CDE also looks like it belongs when
running on Windows or on the Mac. We feel that this is a good thing,
and it is the business of making apps look (and eventually feel) like
they belong that is one of the major motivations of the TkGS project.

Or at least, that's the way *I* see and remember it. YMMV.

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fellowsd@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Hi,

Eugene Dragoev wrote:
[...]
> But I also found that while older versions of Tk were using lightweight
> components (Some Java terminology :) the latest version is using native
> components for things like scrollbars and buttons.
>
> I don't want to say that this is bad for Tcl users but what about all
> the other languages that use Tk? Isn't writting multiplatform GUI harder
> using native components. I think Java made big step forward in
> abandoning the native components and using lightweight ones in Swing.
>
> Is there going to be any Tk implementation that will continue using
> lightweight components?

By lightweight I guess you mean emulated in some way. I don't think that
cross-platform look&feel consistency is a good thing. As a GUI designer
I'd rather follow the principle of least astonishment: an app running on
Windows should look and feel like a Windows app. The same app running on
MacOS and X should do the same on the respective platforms. Such a
cross-platform application is not supposed to look and feel the same on
all platforms. If users want to use the same app on several platforms,
it's their problem, and I think this isn't an issue: if the same person
uses an application on both Mac and Windows, he or she is supposed to
know both platforms, so he won't be surprised if the same application
behave differently on different platforms. On the contrary he or she
would be surprised to use an application that behaves like a Mac app on
his Windows system. The current Tk implementation addresses these
problems in a transparent manner, which is good for both programmers and
users.

A short summary of menubar differences between systems:
- they are placed on top of a window on Windows and X, and on top
of the screen on Mac.
- on Mac, the mouse button must be kept pressed to open and
navigate the menu (until recently). On X, one needs to click on
each menu to open it. On Windows, one needs to click on a menu
but doesn't need to keep the button pressed.

And I don't speak about look differences.

See you, Fred
--
Frédéric BONNET frederic.bonnet@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain

In article <371F11C2.3162025@ciril.fr>, Frederic BONNET
<frederic.bonnet@ciril.fr> writes
>Hi,
>
>Eugene Dragoev wrote:
>[...]
>> But I also found that while older versions of Tk were using lightweight
...
>> Is there going to be any Tk implementation that will continue using
>> lightweight components?
>
>By lightweight I guess you mean emulated in some way. I don't think that
>cross-platform look&feel consistency is a good thing. As a GUI designer
>I'd rather follow the principle of least astonishment: an app running on
>Windows should look and feel like a Windows app. The same app running on
>MacOS and X should do the same on the respective platforms. Such a
>cross-platform application is not supposed to look and feel the same on
>all platforms. If users want to use the same app on several platforms,
...
I take this completely differently; least astonishment for me is if
program X looks and behaves the same way no matter what keyboard, mouse
and screen I'm using. As a 'user' of the program X it shouldn't matter
what OS/WM is executing the code. I certainly don't want vi or emacs to
be different on the mac why should I treat word or excel differently?

Another reason for having a Tk look and feel is that it allows widget
behaviours different from those allowed by the underlying 'convention'.

Of course those with an interest in the survival of rigid wm systems
prefer we should adhere to their conventions. The only changes then come
from the suppler of such systems and are introduced to make us by new
versions etc.

Competition between different WM's is currently almost impossible
because of the original model ie the 'toplevel' is controlled and
decorated by the WM. We don't have to do that with the widgets inside
the 'toplevel' so why do we? Let 100 flowers bloom etc.
...
>And I don't speak about look differences.
>
>See you, Fred

--
Robin Becker

In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
Robin Becker <robin@jessikat.demon.co.uk> wrote:
>I take this completely differently; least astonishment for me is if
>program X looks and behaves the same way no matter what keyboard, mouse
>and screen I'm using. As a 'user' of the program X it shouldn't matter
>what OS/WM is executing the code. I certainly don't want vi or emacs to
>be different on the mac why should I treat word or excel differently?

I would be very surprised if Netscape on the Macintosh presented a
Windows-like user interface, rather than adopting the standard Macintosh
user interface. Most end users don't switch between platforms much, so
it's more important that all the programs on their system conform to their
expectations, than that a particular program work the same across different
platforms.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

On Thu, 22 Apr 1999 18:01:27 GMT, Barry Margolin <barmar@bbnplanet.com> wrote:
>In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
>Robin Becker <robin@jessikat.demon.co.uk> wrote:
>>I take this completely differently; least astonishment for me is if
>>program X looks and behaves the same way no matter what keyboard, mouse
>>and screen I'm using. As a 'user' of the program X it shouldn't matter
>>what OS/WM is executing the code. I certainly don't want vi or emacs to
>>be different on the mac why should I treat word or excel differently?
>
>I would be very surprised if Netscape on the Macintosh presented a
>Windows-like user interface, rather than adopting the standard Macintosh

I'd be very surprised if even 10% of, say, comp.lang.c gave a damn. The pitiful
dumbfuck who started this thread made a severe mistake in constructing the
Newsgroups: header line, the moment he put in the first comma.

I am setting Followup-to: to comp.lang.tcl.

Barry Margolin wrote:
>
> In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
> Robin Becker <robin@jessikat.demon.co.uk> wrote:
> >I take this completely differently; least astonishment for me is if
> >program X looks and behaves the same way no matter what keyboard, mouse
> >and screen I'm using. As a 'user' of the program X it shouldn't matter
> >what OS/WM is executing the code. I certainly don't want vi or emacs to
> >be different on the mac why should I treat word or excel differently?
>
> I would be very surprised if Netscape on the Macintosh presented a
> Windows-like user interface, rather than adopting the standard Macintosh
> user interface. Most end users don't switch between platforms much, so
> it's more important that all the programs on their system conform to their
> expectations, than that a particular program work the same across different
> platforms.

I would have to agree with that statement. While there are those who
think retaining the same look and feel across platforms is necessary, I
would wager they are in the distinct minority. That's not to invalidate
their position, but merely to put it in context. _Most_ users of
software want a package to look and feel like the other packages on a
given system. I hate, for example, the artsy (-fartsy) graphic programs
that have some weird UI instead of a more traditional UI.

On the other hand, to some degree this is application-dependent rather
than user-dependent. For example, if I were to have a requirement to
write a air traffic control program that had to run on BeOS, MacOS, NT
and *nix, I would think there would be significant advantages to keeping
it 100% identical across all platforms. So, to some degree it depends on
the application, or the targeted user base.

My point being, there's a need in the world for both models. Only, the
model where applications should adhere to native conventions is (I'm
guessing) far and away the most commonly expected model by most users.
Which is why I think using native windows on Tk is a win -- it meets the
needs of the majority (though definitely not all) of the users in the
world.

--
Bryan Oakley mailto:oakley@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley

In article <371F11C2.3162025@ciril.fr>, Frederic BONNET
<frederic.bonnet@ciril.fr> writes
>Hi,
>
>Eugene Dragoev wrote:
>[...]
>> But I also found that while older versions of Tk were using lightweight
...
>> Is there going to be any Tk implementation that will continue using
>> lightweight components?
>
>By lightweight I guess you mean emulated in some way. I don't think that
>cross-platform look&feel consistency is a good thing. As a GUI designer
>I'd rather follow the principle of least astonishment: an app running on
>Windows should look and feel like a Windows app. The same app running on
>MacOS and X should do the same on the respective platforms. Such a
>cross-platform application is not supposed to look and feel the same on
>all platforms. If users want to use the same app on several platforms,
...
I take this completely differently; least astonishment for me is if
program X looks and behaves the same way no matter what keyboard, mouse
and screen I'm using. As a 'user' of the program X it shouldn't matter
what OS/WM is executing the code. I certainly don't want vi or emacs to
be different on the mac why should I treat word or excel differently?

Another reason for having a Tk look and feel is that it allows widget
behaviours different from those allowed by the underlying 'convention'.

Of course those with an interest in the survival of rigid wm systems
prefer we should adhere to their conventions. The only changes then come
from the suppler of such systems and are introduced to make us by new
versions etc.

Competition between different WM's is currently almost impossible
because of the original model ie the 'toplevel' is controlled and
decorated by the WM. We don't have to do that with the widgets inside
the 'toplevel' so why do we? Let 100 flowers bloom etc.
...
>And I don't speak about look differences.
>
>See you, Fred

--
Robin Becker

In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
Robin Becker <robin@jessikat.demon.co.uk> wrote:
>I take this completely differently; least astonishment for me is if
>program X looks and behaves the same way no matter what keyboard, mouse
>and screen I'm using. As a 'user' of the program X it shouldn't matter
>what OS/WM is executing the code. I certainly don't want vi or emacs to
>be different on the mac why should I treat word or excel differently?

I would be very surprised if Netscape on the Macintosh presented a
Windows-like user interface, rather than adopting the standard Macintosh
user interface. Most end users don't switch between platforms much, so
it's more important that all the programs on their system conform to their
expectations, than that a particular program work the same across different
platforms.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

On Thu, 22 Apr 1999 18:01:27 GMT, Barry Margolin <barmar@bbnplanet.com> wrote:
>In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
>Robin Becker <robin@jessikat.demon.co.uk> wrote:
>>I take this completely differently; least astonishment for me is if
>>program X looks and behaves the same way no matter what keyboard, mouse
>>and screen I'm using. As a 'user' of the program X it shouldn't matter
>>what OS/WM is executing the code. I certainly don't want vi or emacs to
>>be different on the mac why should I treat word or excel differently?
>
>I would be very surprised if Netscape on the Macintosh presented a
>Windows-like user interface, rather than adopting the standard Macintosh

I'd be very surprised if even 10% of, say, comp.lang.c gave a damn. The pitiful
dumbfuck who started this thread made a severe mistake in constructing the
Newsgroups: header line, the moment he put in the first comma.

I am setting Followup-to: to comp.lang.tcl.

On Thu, 22 Apr 1999 18:01:27 GMT, Barry Margolin <barmar@bbnplanet.com> wrote:
>In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
>Robin Becker <robin@jessikat.demon.co.uk> wrote:
>>I take this completely differently; least astonishment for me is if
>>program X looks and behaves the same way no matter what keyboard, mouse
>>and screen I'm using. As a 'user' of the program X it shouldn't matter
>>what OS/WM is executing the code. I certainly don't want vi or emacs to
>>be different on the mac why should I treat word or excel differently?
>
>I would be very surprised if Netscape on the Macintosh presented a
>Windows-like user interface, rather than adopting the standard Macintosh

I'd be very surprised if even 10% of, say, comp.lang.c gave a damn. The pitiful
dumbfuck who started this thread made a severe mistake in constructing the
Newsgroups: header line, the moment he put in the first comma.

I am setting Followup-to: to comp.lang.tcl.

Barry Margolin wrote:
>
> In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
> Robin Becker <robin@jessikat.demon.co.uk> wrote:
> >I take this completely differently; least astonishment for me is if
> >program X looks and behaves the same way no matter what keyboard, mouse
> >and screen I'm using. As a 'user' of the program X it shouldn't matter
> >what OS/WM is executing the code. I certainly don't want vi or emacs to
> >be different on the mac why should I treat word or excel differently?
>
> I would be very surprised if Netscape on the Macintosh presented a
> Windows-like user interface, rather than adopting the standard Macintosh
> user interface. Most end users don't switch between platforms much, so
> it's more important that all the programs on their system conform to their
> expectations, than that a particular program work the same across different
> platforms.

I would have to agree with that statement. While there are those who
think retaining the same look and feel across platforms is necessary, I
would wager they are in the distinct minority. That's not to invalidate
their position, but merely to put it in context. _Most_ users of
software want a package to look and feel like the other packages on a
given system. I hate, for example, the artsy (-fartsy) graphic programs
that have some weird UI instead of a more traditional UI.

On the other hand, to some degree this is application-dependent rather
than user-dependent. For example, if I were to have a requirement to
write a air traffic control program that had to run on BeOS, MacOS, NT
and *nix, I would think there would be significant advantages to keeping
it 100% identical across all platforms. So, to some degree it depends on
the application, or the targeted user base.

My point being, there's a need in the world for both models. Only, the
model where applications should adhere to native conventions is (I'm
guessing) far and away the most commonly expected model by most users.
Which is why I think using native windows on Tk is a win -- it meets the
needs of the majority (though definitely not all) of the users in the
world.

--
Bryan Oakley mailto:oakley@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley

"Donal K. Fellows" wrote:
>
> In article <371E964F.C531C2A@istar.ca>,
> Eugene Dragoev <eugened@istar.ca> wrote:
> > Is there going to be any Tk implementation that will continue using
> > lightweight components?

Other than comp.lang.tcl, where this should be topical, and comp.lang.c, where
it definitely is not, I have no idea which of the other 4 of the 6 groups give a
tinker's damn about this.

I have reset the followups to this message as comp.lang.tcl. Please do
something similar in your subsequent postings.

Please stop the inane childish massive crossposting. If you want to be known as
unwelcome antisocial polluters of other newsgroups, why don't you just join the
Meow group?

In case you can't understand the above: Take this junk out of the newsgroups
where it does not belong. Think before you you start another idiotic
crosspost. Despite what you might think, usenet is divided into newsgroups for
a reason.




--
Martin Ambuhl (mambuhl@earthlink.net)
Note: mambuhl@tiac.net will soon be inactive

Bryan Oakley wrote:

> Barry Margolin wrote:
> >
> > In article <4fv$ECA+JyH3EwbN@jessikat.demon.co.uk>,
> > Robin Becker <robin@jessikat.demon.co.uk> wrote:
> > >I take this completely differently; least astonishment for me is if
> > >program X looks and behaves the same way no matter what keyboard, mouse
> > >and screen I'm using. As a 'user' of the program X it shouldn't matter
> > >what OS/WM is executing the code. I certainly don't want vi or emacs to
> > >be different on the mac why should I treat word or excel differently?
> >
> > I would be very surprised if Netscape on the Macintosh presented a
> > Windows-like user interface, rather than adopting the standard Macintosh
> > user interface. Most end users don't switch between platforms much, so
> > it's more important that all the programs on their system conform to their
> > expectations, than that a particular program work the same across different
> > platforms.
>
> I would have to agree with that statement. While there are those who
> think retaining the same look and feel across platforms is necessary, I
> would wager they are in the distinct minority. That's not to invalidate
> their position, but merely to put it in context. _Most_ users of
> software want a package to look and feel like the other packages on a
> given system. I hate, for example, the artsy (-fartsy) graphic programs
> that have some weird UI instead of a more traditional UI.
>
> On the other hand, to some degree this is application-dependent rather
> than user-dependent. For example, if I were to have a requirement to
> write a air traffic control program that had to run on BeOS, MacOS, NT
> and *nix, I would think there would be significant advantages to keeping
> it 100% identical across all platforms. So, to some degree it depends on
> the application, or the targeted user base.
>
> My point being, there's a need in the world for both models. Only, the
> model where applications should adhere to native conventions is (I'm
> guessing) far and away the most commonly expected model by most users.
> Which is why I think using native windows on Tk is a win -- it meets the
> needs of the majority (though definitely not all) of the users in the
> world.
>

The two models need not be mutually exclusive. Though I have not had the
pleasure of using SWING for JAVA myself, I believe it offers the ability
to switch look-and-feel at the touch of a button. A configuration option that
would surely please everybody. I would think this kind of configurability is
a good design goal. Of course there are trade offs which are worthy of
discussion. Would some kind soul with experience in this arena care to shed
some light?
Regards,
Bruce A.

In article <37208205.A94D0BC2@istar.ca>,
Eugene Dragoev <eugened@istar.ca> wrote:
>Emulating native components makes the code slower - no doubt about that.
>I was not questioning the use of native widgets in Tcl/Tk but just
>wondering if all the languages that use Tk (Perl/Python etc.) will have
>harder time following the current Tcl/Tk.
.
.
.
You also write, in a related article, that "I just
thought that porting GUI library that contains native
widgets is more difficult." I believe that both of
these perceptions are factually incorrect. As much
as possible (and more as time goes on?), native com-
ponents (in the sense of user interface) are
implemented as native components (that is, by invo-
cation of low-level OS-specific facilities).

In any case, I'm not aware of any particular impact
any of this has on the ease of binding "foreign"
languages such as Perl and Python to Tk.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com +1 281 996 8546 FAX

Where could I find more info about TkGS?

"Donal K. Fellows" wrote:
>
> In article <371E964F.C531C2A@istar.ca>,
> Eugene Dragoev <eugened@istar.ca> wrote:
> > Is there going to be any Tk implementation that will continue using
> > lightweight components?
>
> No current Tk implementation uses lightweight components. All are
> heavy (which actually merely means that they have their own window
> each.) One of the things that might come out of the TkGS work at some
> point may be lightweight components. There are other issues being
> resolved there first though...

In article <3721631D.8642F0AA@istar.ca>,
Eugene Dragoev <eugened@istar.ca> wrote:
>Where could I find more info about TkGS?
.
.
.
<URL:http://x12.dejanews.com/viewthread.xp?search=thread&recnum=%3c3714B0BA.9F418298@ciril.fr%3e%231/1>
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com +1 281 996 8546 FAX