Fwd: OBSystemBrowser vs. Browser

---------- Forwarded message ----------
From: Lukas Renggli <[hidden email]>
Date: Jan 30, 2008 11:58 AM
Subject: Re: OBSystemBrowser vs. Browser
To: OmniBrowser developers <[hidden email]>


> Do you refer to a task bar like the ones in Windows, KDE or Gnome? If
> yes, then this task bar exists and is activated by default in all
> squeak-dev beta images (ftp://ftp.ofset.org/squeak/squeak-dev/beta).

I tried the TaskBar in your image, this is a really cool extension for
Squeak. What is missing is an X, to be able to close the window right
from the task bar. Also some keybindings would be nice to switch to
the next window.

--
Damien Cassou
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Of course, the context menu for taskbar buttons is only available if the existing "generalizedYellowButtonMenu" preference is switched off (don't ask why!).
As for window switching, alt-leftArrow/alt-rightArrow was the only combination I could find that wouldn't conflict with (mostly text) morphs and the host OS.

All described here http://wiki.squeak.org/squeak/6005

Gary.

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

> Of course, the context menu for taskbar buttons is only available if the existing "generalizedYellowButtonMenu" preference is switched off (don't ask why!).
> As for window switching, alt-leftArrow/alt-rightArrow was the only combination I could find that wouldn't conflict with (mostly text) morphs and the host OS.
>
> All described here http://wiki.squeak.org/squeak/6005

This is really cool. Thanks for the pointers.

Even if this is getting more and more off-topic, what would it take to
get the focus detached from the mouse?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Which focus. There are some preferences for mouseClickForkeyboardFocus
(should be on) and existing mouseOverForKeyboardFocus (should be off).
With the latest Widgets the mouse wheel can be used independently of
keyboard focus.

Gary.

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Lukas,

Gary provided the authoritative answer, to which I will add that a stray
method to set the various preferences might be helpful.  We will all
have our own variants, but it is getting hard to tell which options are
not truly independent.  FWIW, it is a great problem to have.

As far as keyboard focus being off topic: it is **ON TOPIC**.  I wish
you guys could have heard Aileen type.  Failing that, watch a clerk who
has learned how to work without a mouse (and hates having to stop to
touch it) pound on a keyboard.  We should be able to meet their
expectations.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 01/30/08 7:52 AM >>>
> Of course, the context menu for taskbar buttons is only available if
the existing "generalizedYellowButtonMenu" preference is switched off
(don't ask why!).
> As for window switching, alt-leftArrow/alt-rightArrow was the only
combination I could find that wouldn't conflict with (mostly text)
morphs and the host OS.
>
> All described here http://wiki.squeak.org/squeak/6005

This is really cool. Thanks for the pointers.

Even if this is getting more and more off-topic, what would it take to
get the focus detached from the mouse?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

The following is from a different subject but I find it more appropriate
for the "Promote Squeak/Smalltalk" thread:

Bill Schwab schrieb:
Meeting expectations is a good catchword. And to make a long story short:
Squeak is often advertised as being "multi platform" and having a decent
class library.
In my experience the reality is different:
Windows is supported best, followed by Mac and Linux x86.
Every other platform has more or less problems:
- On Solaris (x86 and SPARC): FFI is not supported and thus no depending
packages like
   ODBC (so no generic database connectivity).
- Are there any actual VMs and images for ARM, MIPS or something similar?
- What about Linux on non-Intel?

Another, often discussed problem area for Squeak is its not standard
conforming GUI.
It may be that Morphic is in many areas superior to most other GUI
frameworks. Nevertheless
it is very difficult and annoying to create GUIs for standard business
applications
(eg. the aforementioned bank account SW).

Code quality and documentation is another major concern. There is a lot
of brilliant code
in the Squeak base. But there is also a lot of mess in it. And you can
be sure that most
experienced programmers will find many more occurrences of mess than
brilliant code.
At least the mess is more likely to be remembered.
Furthermore it is quite easy to find problems and annoyances in the
tools of a standard image.
(BTW I have similar experiences with ST/X. It takes only a few minutes
to find MNUs in the
standard tools.)

Did I mention that Squeak is sometimes painfully slow on my Sun Blade
2000 (equipped with
two US-III+ processors and 8GB RAM)? This has two causes: gcc produces
slow code for SPARC
(and Sun C and its tool chain is not quite supported) and Morphic (or at
least most of Squeak's
GUI) is painfully slow.

Regards
Andreas

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

On 30-Jan-08, at 1:20 PM, Andreas Wacknitz wrote:
>
> - Are there any actual VMs and images for ARM, MIPS or something  
> similar?
Why do you think a special image is needed? I've supported Smalltalk  
in various forms on RISC OS (the original ARM supporting OS) for 20  
years and can assure you no special image has ever been needed for any  
particular processor. It's the OS that makes the difference - assuming  
vaguely decent C development tools - and then only really to the VM.  
Barring of course small matters in FFI type image support.

If you have a machine with a functioning processor and an SDK that can  
compile a VM then you can make Squeak run on it.  How do you think we  
got Squeak running on non-Mac machines in the first place?

>
> - What about Linux on non-Intel?

What about it? Certainly Ian P. used to run a PPC laptop with linux  
and Squeak. I worked on a linux/ARM machine for one job.

Not to mention that realistically speaking there are only two CPU  
architectures that matter these days - intel-x86-descended-whatever  
and ARM. Pretty much everything else is now minor niche market. Cell  
might possibly become important sometime.

>
>
> Another, often discussed problem area for Squeak is its not standard  
> conforming GUI.
Which standard do you want? There's rather a lot of them, most awful.  
Win3.0? Win 3.1? 95? XP. please, not Vista.... Mac OS-7.6? 9.1? OSX  
10.1/2/3/4/5? TWM? Gnome? KDE?
Any of them could be implemented if people actually wanted them enough  
to pay for the work.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- He has a tenuous grip on the obvious.


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

tim Rowledge schrieb: I wanted to point out that there is a mismatch between "We have many
supported platforms and a rich class library / many packages" and the
ability
to use all of the functionality on these platforms. I only managed to
get ODBC running on Windows. Thus all other platforms, especially Mac and
Solaris have no generic database support.

>
> If you have a machine with a functioning processor and an SDK that can
> compile a VM then you can make Squeak run on it.  How do you think we
> got Squeak running on non-Mac machines in the first place?
>
I know that this is possible. But if we are talking about attraction for
Squeak to new developers it doesn't sound so good to say:
"You can always port it to your platform or pay for a port" when a JVM
is available for free and frameworks like JDBC and Hibernate.
Sorry, I have a different opinion here as I own two SPARC workstations.
When your argument is valid, there were also only a few programming
languages relevant these days: C, C++, C# and Java. All others are just
minor niche. Albeit Ruby may become important sometime.
Most of your mentioned GUIs have commonalities that makes it possible
for programmers to create the "standard business" GUIs and for users to
actually use them. See some older discussions in this list for some
problem areas Squeak's GUI has.

Andreas
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Andreas,

Some random thoughts:

The standard (and not altogether unreasonable) answer to "no support for
x on y" is "Want FFI on Solaris? Write it."  You are correct in pointing
out the deficiencies; "they" are correct in pointing out that "we" could
help more.  Sadly, I suspect many would help more if help were more
aggressively accepted.

I accept some blame for failing to make it easier to write certain apps.
 I really should put an MVP wrapper around some of the morphic chaos.
Various things have distracted me, including learning more about Linux -
Squeak is of dubious value to me if I stay on Windows, hence the
diversion.  Ubuntu installs quite easily, though an upgrade to 7.10
fried my VPN (getting to be a pain) and added/revealed some largely
cosmetic bugs.  I also want to get craftier with shell scripts.  I am
starting to think fondly of "reinstall, run custom script, return to
find re-configured machine."  Come to think of it, I want the same thing
for Squeak, getting the latest version of various things (Gary's work
being high on the list) w/o having to click and wait my way through a
GUI.  No lack of gratitude implied; the GUIs are great, but sometimes a
script is the better way to go.

I also looked at ST/X, and found pretty much what you did.  It has
strong supporters, but early experiments left me concerned that it would
fail a lot too easily for my taste and needs.  

Re Squeak's GUI speed, have you tried some older versions?  IIRC, Squeak
took a real speed hit somewhere around 3.8 or 3.9????  That's not to say
"downgrade or suck it up," but I _am_ curious if older versions are
faster.  One nice thing about slow platforms is that slow code crawls
all the more on them.

To add a concern to your list, what about incompatibilities with other
dialects?  To continue my rant about streams,

   'hello' at:200

raises an error, but 'hello' readStream next:200 truncates.  Hmmmm.
Dolphin and VW get this one right.  Nile includes some beginning efforts
to rewrite some methods to use its streams, but to really fix it (I
think) requires a breaking change.  I am tempted to turn the RB loose to
turn #next into #nextOrNil and #next into #nextAvailable: (there might
be others I have yet to recognize), and then begin work in the new image
after adding some methods and/or switching to Nile.  Add confusion over
that to my list of reasons/excuses for delay in MVP ;)  Humor aside, it
*is* a concern to me.

So, what are we going to do to fix all of this stuff?

Bill





Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 01/30/08 4:20 PM >>>
The following is from a different subject but I find it more appropriate

for the "Promote Squeak/Smalltalk" thread:

Bill Schwab schrieb:
> Lukas,
>
> Gary provided the authoritative answer, to which I will add that a
stray
> method to set the various preferences might be helpful.  We will all
> have our own variants, but it is getting hard to tell which options
are
> not truly independent.  FWIW, it is a great problem to have.
>
> As far as keyboard focus being off topic: it is **ON TOPIC**.  I wish
> you guys could have heard Aileen type.  Failing that, watch a clerk
who
> has learned how to work without a mouse (and hates having to stop to
> touch it) pound on a keyboard.  We should be able to meet their
> expectations.
>
>  

Meeting expectations is a good catchword. And to make a long story
short:
Squeak is often advertised as being "multi platform" and having a decent

class library.
In my experience the reality is different:
Windows is supported best, followed by Mac and Linux x86.
Every other platform has more or less problems:
- On Solaris (x86 and SPARC): FFI is not supported and thus no depending

packages like
   ODBC (so no generic database connectivity).
- Are there any actual VMs and images for ARM, MIPS or something
similar?
- What about Linux on non-Intel?

Another, often discussed problem area for Squeak is its not standard
conforming GUI.
It may be that Morphic is in many areas superior to most other GUI
frameworks. Nevertheless
it is very difficult and annoying to create GUIs for standard business
applications
(eg. the aforementioned bank account SW).

Code quality and documentation is another major concern. There is a lot
of brilliant code
in the Squeak base. But there is also a lot of mess in it. And you can
be sure that most
experienced programmers will find many more occurrences of mess than
brilliant code.
At least the mess is more likely to be remembered.
Furthermore it is quite easy to find problems and annoyances in the
tools of a standard image.
(BTW I have similar experiences with ST/X. It takes only a few minutes
to find MNUs in the
standard tools.)

Did I mention that Squeak is sometimes painfully slow on my Sun Blade
2000 (equipped with
two US-III+ processors and 8GB RAM)? This has two causes: gcc produces
slow code for SPARC
(and Sun C and its tool chain is not quite supported) and Morphic (or at

least most of Squeak's
GUI) is painfully slow.

Regards
Andreas

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Bill Schwab schrieb:
> Andreas,
>
> Some random thoughts:
>
> The standard (and not altogether unreasonable) answer to "no support for
> x on y" is "Want FFI on Solaris? Write it."  You are correct in pointing
>  
I know this, alas this is not so easy as it sounds. FFI uses libffi. And
libffi is now a part of
gcc. It seems as if I had to tame that beast and some other dependencies
first.

> out the deficiencies; "they" are correct in pointing out that "we" could
> help more.  Sadly, I suspect many would help more if help were more
> aggressively accepted.
>
> I accept some blame for failing to make it easier to write certain apps.
>  I really should put an MVP wrapper around some of the morphic chaos.
> Various things have distracted me, including learning more about Linux -
> Squeak is of dubious value to me if I stay on Windows, hence the
>  
I once was a big Linux fan. That changed when I realized that there is
no such thing like
"Linux the operating system". There is "Linux the kernel" that is used
by different companies
and organizations to build their own Linux based operating systems.
But they are free to add/patch/remove things to the Linux kernel and
combine this with any
kind or version of X11, KDE, GNOME, ... and so on. This is a support
nightmare for a software
creator. Sooner or later one recognizes a new kind of dependency hell.
This was the major motivation for me to choose Solaris. Alas with
Solaris you have to fight the
Linuxisms and GNUisms because everybody expects the C compiler to be gcc
and most other GNU
tools in the tool chain.
Of course I have. And in fact the older versions feel more responsive.
But older versions lack
some things that were introduced in 3.9 and 3.10. And older versions
look more terrible than
3.9 or 3.10 for me. Furthermore I have the feeling that you have to
follow bugs.squeak.org for
bug reports and fixes and have to patch your image on your own as most
of the fixes are only
incorporated in the version that is actually being worked on. Yes, this is a big concern for Smalltalkers using different Smalltalk
dialects. You can add
non-standard GUI frameworks, sockets and nearly all things not defined
by the ANSI standard
to this list.  But this is usually not a problem during the first
experiments of newcomers.

Regards
Andreas
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui