subject:"RE\: \[ql\-users\] The future of SMSQ\/E"


Dilwyn Jones wrote: 
 One example: could SOQL or an equivalent be bolted onto SMSQE as a
 module to give the OS some degree of internet access capability?

Adding a module to SMSQ/E is not much different from LRESPERing some
extension.

Marcel

Re: [ql-users] The future of SMSQ/E


Dilwyn Jones wrote: 
 Exactly. Tools like Easyptr to help BASIC and C programmers. Did QPTR
 Toolkit get updated for GD2 at all?

Well, how could it? The whole thread is about creating a high colour
capable PE first...

Marcel

Re: [ql-users] The future of SMSQ/E

2002-03-13 Thread Francois Lanciault


Marcel,

Could you please, PLEASE add GD2 support to the Aurora ? It would add a lot of users 
to High Color migration. I know it is probably not easy but I'm sure Nasta will help !!

Regards,
Francois Lanciault

Re: [ql-users] The future of SMSQ/E


ZN wrote:
[slave block]
 Yes, I think that is something that needs to be addressed at the very least
 concurrently with the added WMAN options, because with more colors and
 large save areas more memory is needed, but when more memory is configured,
 slave blocks slow everything down to a crawl.

Addendum:
The fast memory trick seems to do it, I now have a test version of QPC
that only uses the first MB of RAM for slaving. It is just irritating
that all functions to determine the remaining free memory of course
refer to this (s)low memory, so it always shows that 847kb are free,
although there are e.g. at least 30MB more (fast memory) available.

Does anybody here have experience with Ataris and fast memory? Are
there fixes available for the problem, are there other problems as
well?

Marcel

Re: [ql-users] The future of SMSQ/E

2002-03-13 Thread ZN


On 3/13/02 at 10:06 PM Marcel Kilgus wrote:

 Now that you mention stippling, it is my opinion that when having
 16 bit colours there is no need for stipples anymore (I mention this
 because I've heard that Tony invested quite a lot of thinking about
 how to get stipples in). What is the general opinion about that?

My opinion would be that it would be nice to have a thing that could
calculate a 16BPP (or 15BPP) stipple of sorts out of a 24BPP definition so
applications can use this but I don't think it really needs to be
implemented as part of the PE (not to mention that it seems to be very
difficult). I can hardly see a need for a user interface to use more than
32/64k colors.

 Hmm, on the one hand there's already the normal palette mode which is
 well defined and I think it's unlikely that the user changes it.

 Which one would that be? i hope we are not talking about the 256 color
 system palette imposed by the PC? Or am i missing something?

No, I mean the palette SMSQ uses on palette calls. It's predefined
with certain colours (list is at the end of GD2 docs) and I think that
most people will leave it this way.

Ah... I see.

 IMHO this might prove to be a serious problem in the future given
 the philosophy of WMAN - simply because the save areas increase
 8-fold, the consequence of which is the speed of their manipulation
 decreases by the same factor.

 I know...
 Most manipulations aren't really much slower than their 2bit
 equivalent, the calculations are a lot simpler. The problem comes when
 big chunks of memory need to be altered

That's precisely what I meant. Scrolling must be the biggest issue, but in
an environment with background update, this is an issue one cannot really
solve (just thinking in advance here).

 Finally in the end there should be a standard graphics library thing
 which can be consulted for all things involving graphics manipulation,
 like colour conversions so that not every single application has to
 implement that stuff etc. And those routines could be accelerated,
 too.

All I can say is: AMEN!

 It really undermines one of it's best qualities: speed/simplicity.
 Just don't get me wrong, I don't think this is something that needs
 immediate attention...

 Well, I really hope that people make their applications more
 colourful. I do encourage to brush up older applications

Agreed - the question being, HOW colorful do they need to be? Certainly not
4 colors. 16 would already be more like it, 256 is already pushing it a
bit. Mind you, the idea is to have whatever number of colors chosen from a
15BPP palette, so essentially, they get more colorfull eve if they only use
4 colors.

 e.g. Jochen is currently trying to get the QPAC2 source code so that
 we/I can extend it. This is very important in my eyes).

Agreed.

 But I need to know how much save area to allocate beforehand. What
 happens if an application is considered 2bit only and all of a sudden
 it issues an iow.papt (true colour paper trap) call with some exotic
 colour?

The result would be the use of the aforementioned thing that does color
conversion, and the result of that would be a 2-bit stipple definition. See
below.

 What I meant is that hardware capable of doing 4 colors can still show
 the 4 colors and given proper screen drivers, 'lesser mode' applications
 will still work without modification, just like they do now with the new
 drivers.

 I'm not completely sure whether I get this right, you're proposing
 some sort of the old MODE4-MODE8 switch? Well, for one I don't like
 that and hardware like the Qx0 do make a problem there because the 4
 colour mode is restricted to the poor 512x256 resolution.

No, the 'mode switch' would really only establish what kind of save area te
job needs and change the way a color definition as given is interpreted by
the driver - It would be a 'property' linked with the main application
window. There would also be a 'system variable' where the default for this
would be set if the job does not provide a value.
The idea is precisely not to have the jobs know they are running in a
particular mode unless they ask for it speciffically. This is a big plus
because even with your extensions to the PE, you will hardly tend to use a
large number of colors. If you define the system default to be 16 colors,
and use a real screen at 16BPP, programs that don't specify a mode will use
16 colors - if so desired out of a palette of whatever number of colors the
actual hardware provides. The color conversion routines take care that when
a job specifies a color, you get something close to it on the screen. If
your actual screen is not set for many colors or it simply can't do it, you
gat a stipple. The idea is to remove the need for programs to cater for
multiple screen modes which certainly does not help things right now. The
system palette is a huge help with this.
Now, don't get me wrong, I fully understand that this is a VERY tall order.
And it's not something to do _right_now_ but

Re: [ql-users] The future of SMSQ/E

2002-03-13 Thread P Witte


Marcel Kilgus writes:

 Arnould Nazarian wrote:
  This is only to stress again on the point that the routines seem to be
  foreseen for proportional printing on screen: that is why characters can
  be placed with pixel accuracy both in QDOS and the PE. So it should be
  feasible, and the main hassle would be with old QLers using old software
  that would not work as expected.

 It's not only old software, every software that tries to calculate the
 size of a string in any way (e.g. something as simple as the button
 frame) would fail (look ugly). So the system would need to distinguish
 between the old and new fonts, new system routines would be needed
 that calculate the width of a character/string and probably much more.

I think the Psion Series 3's OPL had a good approach to this, as it
implemented fixed fonts parallel to graphics fonts. You could use PRINT,
LEN, AT, etc or gPRINT, gLEN, gAT. gLEN would return the pixel length of a
string, for example. You get the idea. Best of both worlds leaving the old
world intact. OPL is very much like S*Basic in many ways.

Per

Re: [ql-users] The future of SMSQ/E

2002-03-13 Thread P Witte


Marcel Kilgus writes:

 After the Hove show some of us went to a pub and discussed a bit about

I like your proposals. Anything that simplifies the process of
program-creation as well as enhances the usability and aesthetics must be A
Good Thing. Amen.

 Next question, what should be included in the system palette? My
 preliminary list is the following:

 Window paper

Might it be an idea to build a layer on top of that, a la Colourways/Themes?

Per

Re: [ql-users] The future of SMSQ/E


P Witte wrote: 
 Next question, what should be included in the system palette? My
 preliminary list is the following:

 Window paper
 Might it be an idea to build a layer on top of that, a la Colourways/Themes?

Do you mean to manage a complete, exchangeable set of colours? I don't
think that is must be part of the PE, this can in the end be done by
3rd party tools.

Marcel

Re: [ql-users] The future of SMSQ/E

2002-03-13 Thread ZN


On 3/14/02 at 3:29 AM Marcel Kilgus wrote:

ZN wrote: 

 manipulations aren't really much slower than their 2bit equivalent
 ... The problem comes when big chunks of memory need to be altered

 That's precisely what I meant. Scrolling must be the biggest issue,

 On QPC this is actually faster than (or at least as fast as) the 2bit
 routines due to the acceleration.

Certainly, alas with other hardware there is no such luxury, but this is
not a huge problem.

 but in an environment with background update, this is an issue one
 cannot really solve (just thinking in advance here).

 I don't completely get that comment.

If programs start writing into their save areas always and onto the screen
only when they are on top of the job stack, the amount of manipulations
increases dramatically. An approach where save areas are kept at optimum
BPP depth would help this - but the next step would be to provide an update
of the partially burried windows and this is where we run into problems
again.

A little explanation (I'm sure nothing new for Marcel!) here:

In systems where the job itself is responsible for updating a window, it
knows when something has really been changed in it (and if it's clever
enough, where) and updates the visible part. Alas, WMAN is not such a
system.
In a system like WMAN where a bitmap (essentially = save area) is used per
job, there has to be a job or a task (I would favour the latter and I'll
explain why below) that periodically 'combs' through all the save areas of
all partially visible windows (the top job window refresh is, or rather,
may be, treated differently) and copies them onto the actual screen. If
save areas are alowed to have a format different than the actual screen
layout on given hardware, this refresh job also has to do color conversion
from save area format to actual screen format 'on fly', and it gets to know
how by reading the relevant structures in window/job definition blocks
(this here is a prime candidate for acceleration of some sort). It would be
possible (but not strictly necessary, it could mean a LOT of added work) to
include a mechanism where this 'refresh' task can read a 'changed' status
of some sort for a save area or window within it, so it skips parts that
have not changed. This is where we get into quite a lot of manipulations
again, but fortunately, the total maximum number of pixels manipulated is
equal to the screen resolution, and all of this does not have to occur
'real time' so the actual load to the system is limited.

Now, although my point is made, I'd like to explain why I keep bringing up
variable format save areas, and more specifically drivers that operate on
save areas rather than / in addition to the actual screen.
Well, WMAN with it's save area concept is one step away from a full
'virtual screen' setup. When drivers write into save areas, the actual
screen resolution, organization and size, become less relevant:
1) There is no reason for a save area to have a size limited to the screen
size - manipulating it would require changes to the GUI, not to the
application - but of course, the application can be made aware of this
possibility and alowed to handle it.
2) There is no reason for a save area to have the same pixel organization
as the screen - this immensely helps with compatibility across platforms,
and has another interesting consequence: a save area can have an
organization that no available screen hardware implements (yet)
All of this is subject to:
a) available memory (here is where optimized save areas can help a lot)
b) availability of a driver for a given save area format (we already have
4, 8, 32, 33) - applications can be alowed to handle some or all operations
where necessary (for instance, where an application wants to internally run
in 24BPP)
c) ability of the system to transalte from save area format to actual
screen format with usable ('real time') responsiveness - again, save area
formats can help here, and again, there may be a mechanism for applications
to provide their own 'transaltors'.

In theory, NO program should need to write to he actual screen RAM at all -
as long as there is a documented data structure that keeps track of where
the 'virtual screen' (read fancy save area) is and what format it has
(presumeably one that the screen refresh task understands). It would be the
screen refresh task's... well, task, to bring the contents of the 'virtual
screens' to the real one so they can be viewed, with whatever rules one
cares to impose based on the visibility of a job's window (for instance,
the top job gets most attention, partially visible jobs are refreshed less
often). This also has some interesting repercussions on a GUI overlay, if
one is used.

The validity of this concept has already been demonstrated, on the QXL
(sadly it's slow due to hardware limitations) and on QPC - albeit on one
'virtual screen' - namely the emulation of the real one. From the
standpoint of the host machine, the QL screen RAM is

Re: Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread John Hall


Ian Pine wrote:

 In my opinion we should be looking at small tweaks to the OS,
 finding opportunities to make it more efficient, adding only enough
 features to make it keep up with hardware developments, while
 keeping it compact.
 Larger projects should certainly be developed, but they should be in
 the form of application layers, that can be loaded or not, as the
 user chooses.

 If it moves too far from the original QL look  feel - more
 Windows-like or more Unix-like and users aren't given the choice of
 which interface style to use, the platform will lose its identity,
 then what is there to make us choose it over a PC running one of
 those other operating systems?  Perhaps we should take a risk and
 stay defiantly different - that might attract some new users who are
 curious, attracted precisely because it IS different.  But some of
 the minor irritations need to be tidied up first.

I agree. SMSQDOS will never be a mainstream OS and if we try to make
it one we'll just end up losing its distinctive character.

Also, we should be wary of asking for too much and ending up with
nothing. Marcel and Jochen have reluctantly concluded that if anything
is going to get done, they're going to have to do it. We should be
grateful for whatever they are able to do to WMAN and encourage them
to make further surgical strikes on SMSQ/E .

John
--
[EMAIL PROTECTED]

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread Phoebus Dokos


At 08:35 ÐÌ 12/3/2002, you wrote:

Phoebus Dokos wrote:
 b) I can tell you that there aren't thousands of QPC users out there
 and even less Qx0 users, so how big could a potential ArmQL user base
 be in the end? I say that a value with 3 digits is already a big goal.
 
  Not really because due to its platform the ArmQL CAN be used as a QL but
  not only for that, it can run RiscOS, Linux / Net(Open) BSD and even 
 PalmOS
  :-) (V. 5 and above)... and with a potential for handheld operation as well
  :-) (Or industrial apps etc. etc. etc...)

Fine, but this doesn't increase the user base for a potential SMSQ
window manager, does it?

It will if you take into account a handheld QL :-) (Now you can't have a 
keyboard on a handheld can you? You need Icons :-)

RE: [ql-users] The future of SMSQ/E

2002-03-12 Thread Claude Mourier 00


I think your idea is the only one worthwhile : at the moment I don't use
more than 4 colours (QPC2) because I can't do nothing except viewing jpeg, a
work where Windows program are far more advanced and fast (using 16 bit
colour only slow down SMSQ -no need compared with PC-, gives strange effects
with old program... and crash my system if I use Prowess applications).
What we need is a tool or something that help developpers/users to use more
colours.

Claude

-Message d'origine-
De : Marcel Kilgus [mailto:[EMAIL PROTECTED]]
Envoyé : mardi 12 mars 2002 14:35
À : ql-users
Objet : Re: [ql-users] The future of SMSQ/E


Phoebus Dokos wrote: 
b) I can tell you that there aren't thousands of QPC users out there
and even less Qx0 users, so how big could a potential ArmQL user base
be in the end? I say that a value with 3 digits is already a big goal.

 Not really because due to its platform the ArmQL CAN be used as a QL but 
 not only for that, it can run RiscOS, Linux / Net(Open) BSD and even
PalmOS 
 :-) (V. 5 and above)... and with a potential for handheld operation as
well
 :-) (Or industrial apps etc. etc. etc...)

Fine, but this doesn't increase the user base for a potential SMSQ
window manager, does it?

Marcel

Re: [ql-users] The future of SMSQ/E


[EMAIL PROTECTED] wrote: 
 In my opinion we should be looking at small tweaks to the OS, finding
 opportunities to make it more efficient, adding only enough features to 
 make it keep up with hardware developments, while keeping it compact.

Exactly my idea. There won't be any new window manager, at least not
from me, so the whole discussion might be nice from a theoretical
point of view but that's it.

I see it this way: if I had put all the hours into something
commercially viable instead of QPC there would be a Ferrari waiting
outside instead of a Mitsubishi. I don't regret doing it, it's still
fun and I'm happy to donate some of my time to the scene. But what I
certainly won't start is yet another project that would eat up my
hours by the hundreds.

And anyway, if I wanted a completely different look I would just start
changing ProWesS instead of doing the same thing again. Some think
ProWesS would be faster if written in assembler? Then feel free to do
so, the source is right there. But nobody will do so because nobody is
willing to invest that much time (or those who might be willing don't
have the knowledge which in the end results in the the same fact:
nothing done).

I'm trying to tweak the code that is already there and do the stuff
that just needs to be done. And I'm trying to involve you into the
decisions I have to make as much as possible. Unfortunately not much
feedback there so far.

Marcel

RE: [ql-users] The future of SMSQ/E

2002-03-12 Thread Claude Mourier 00


I'm affraid a Ferrari waiting outside is not faster than a Mitsubishi 

Claude
-Message d'origine-
De : Marcel Kilgus [mailto:[EMAIL PROTECTED]]
Envoyé : mardi 12 mars 2002 14:33
À : ql-users
Objet : Re: [ql-users] The future of SMSQ/E

(...)
I see it this way: if I had put all the hours into something
commercially viable instead of QPC there would be a Ferrari waiting
outside instead of a Mitsubishi. I don't regret doing it, it's still
fun and I'm happy to donate some of my time to the scene. But what I
certainly won't start is yet another project that would eat up my
hours by the hundreds.
(...)

Re: RE: [ql-users] The future of SMSQ/E

2002-03-12 Thread Phoebus Dokos


??? 12/3/2002 9:30:01 ÐÌ, ?/? Claude Mourier 00 [EMAIL PROTECTED] ??:

I'm affraid a Ferrari waiting outside is not faster than a Mitsubishi 

Claude

Especially if it doesn't move :-)


(...)
I see it this way: if I had put all the hours into something
commercially viable instead of QPC there would be a Ferrari waiting
outside instead of a Mitsubishi. I don't regret doing it, it's still
fun and I'm happy to donate some of my time to the scene. But what I
certainly won't start is yet another project that would eat up my
hours by the hundreds.
(...)





However the point Marcel makes is strong and totally understandable, and that is
why I am saying about others doing the work whereas Marcel could provide the input 
that TT could or would never provide :-)
And finally approving it anyway :-)


--
Phoebus R. Dokos - Quantum Leap Software
Web and Graphic Design - Custom Program Solutions
Tech Support - Software Localization
Web: http://www.dokos-gr.net
ICQ#:34196116 / SMS:+30973267887
SMS:[EMAIL PROTECTED]

Re: RE: [ql-users] The future of SMSQ/E

2002-03-12 Thread Phoebus Dokos


??? 12/3/2002 9:37:30 ÐÌ, ?/? Norman Dunbar [EMAIL PROTECTED] ??:

Marcel,

Putting aside any new GUIs for the moment, I would thing that your original
proposals are a good idea.
The caveat must be that the new colour schems/codes etc MUST not interfere
with existing PE programs.

I particularly like the idea of a standard set of colours for various items,
which leaves the user free to configure his/her system to their own colour
schemes, and have the programs they run adopt that scheme. (I hesitate to
say, but this is one of the better examples of something Windows does)

I say 'go for it'.

Regards,
Norman.


As I said me too :-). First of all it significantly simplifies development. 
I also believe that (once again) I was misunderstood. When mentioning leaving the PE 
aside and making something different,
I wasn't referring in not improving what is available RIGHT now, but just to leave on 
the side any attempt to make the PE what it is 
not :-)
ANY enhancement that makes the programmers (and users) lives' easier is EXTREMELY 
welcome in any case... Now about that 
Filesystem :- hehe


--
Phoebus R. Dokos - Quantum Leap Software
Web and Graphic Design - Custom Program Solutions
Tech Support - Software Localization
Web: http://www.dokos-gr.net
ICQ#:34196116 / SMS:+30973267887
SMS:[EMAIL PROTECTED]

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread Dexter



Different email for a while... But here goes...

On Tue, 12 Mar 2002, Marcel Kilgus wrote:

 Phoebus Dokos wrote: 
 b) I can tell you that there aren't thousands of QPC users out there
 and even less Qx0 users, so how big could a potential ArmQL user base
 be in the end? I say that a value with 3 digits is already a big goal.
 
  Not really because due to its platform the ArmQL CAN be used as a QL but 
  not only for that, it can run RiscOS, Linux / Net(Open) BSD and even PalmOS 
  :-) (V. 5 and above)... and with a potential for handheld operation as well
  :-) (Or industrial apps etc. etc. etc...)
 
 Fine, but this doesn't increase the user base for a potential SMSQ
 window manager, does it?

That's not the purpose of ArmQL.

ArmQL is just a project I am working on very, very slowly. It has low 
priority at present, and could take 9-12 months to complete. So it's not 
immediately relevant. However, it will be relevant in a year.

By then, we will have Goldfire (or whatever it is called by then). It will 
be much easier for people to upgrade their existing machines to Q60 
performance levels without the expense of a Q60, but that does not 
increase the total number of systems out there, so it doesn't increase the 
QL user base directly, until Aurora II comes along.

The Q40 and Q60 are relatively expensive, and represent a brute-force 
approach to the problem. They're immensely powerful, and emulate the QL at 
a hardware level, so that's pretty much all they can do (at present).

The idea is to at least have an option, which exists as software, to buy a 
QL with at least moderate performance, lots of interfaces, and low cost. 
The ability to run other OSes *is* the point. If it is more widely 
manufactured, and sold into other markets that WILL support a profit, this 
will reduce unit costs for you. Significantly.

An ArmQL isn't entirely relevant now, but in a year, when Motorola's 
processor roadmap is more clear, it may take on a much greater 
significance.

IMHO
Dave

RE: [ql-users] The future of SMSQ/E

2002-03-12 Thread Norman Dunbar


And the example, which I have finally managed to see - your web site was
always timing out earlier - is excellent !

Cheers,
Norman.

-
Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:[EMAIL PROTECTED]
Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
-


-Original Message-
From: Marcel Kilgus [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 2:51 PM
To: ql-users
Subject: Re: [ql-users] The future of SMSQ/E

 The example I put on
 the web was done using a simple hex editor and an existing PE
 application.

Marcel
This email is intended only for the use of the addressees named above and
may be confidential or legally privileged.  If you are not an addressee you
must not read it and must not use any information contained in it, nor copy
it, nor inform any person other than Lynx Financial Systems or the
addressees of its existence or contents.  If you have received this email
and are not a named addressee, please delete it and notify the Lynx
Financial Systems IT Department on 0113 2892990.

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread Malcolm Lear


That's excellent news Marcel. Total compatibility and a much better 
looking PE.

Malcolm


Marcel Kilgus wrote:

 Norman Dunbar wrote: 
 
 Putting aside any new GUIs for the moment, I would thing that your original
 proposals are a good idea.
 The caveat must be that the new colour schems/codes etc MUST not interfere
 with existing PE programs.
 
 
 Thanks. The nice thing is that all old programs will work like before
 but can easily be adapted for using more colours. The example I put on
 the web was done using a simple hex editor and an existing PE
 application.
 
 Marcel

Re: [ql-users] The future of SMSQ/E





 
 IMHO what should be done is to leave WMAN alone and work 

 on an entire new PE that could give the QL a whole new GUI,

I for one completely disagree with this. There is Prowess
as others said, and there are certainly things to do at
lower level the GUI in SMSQ/E.

Arnould

Re: [ql-users] The future of SMSQ/E



 
 It's not so much asm vs. C but vector fonts vs. simple fixed fonts.

One of my wishes for a long time is printing on screen with fixed size 
proportional fonts at OS level. If possible by reusing the Text87 fonts 
because there are a lot around. That would be fast, and still 
interesting effects could be achieved even in todays PE.

TT told me that this would be a few hours of work and Joachim told
that, for TT, it would be half a day's of work.

But TT also told me that there would immediately be some 
incompatibilities with old software, and that he doesn't want to take 
the risk of that hassle.

Arnould

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread Dexter


On Tue, 12 Mar 2002, Arnould Nazarian wrote:

  on an entire new PE that could give the QL a whole new GUI,
 
 I for one completely disagree with this. There is Prowess
 as others said, and there are certainly things to do at
 lower level the GUI in SMSQ/E.

Party busting up time...

The current GUIs *suck* - sorry to those who wrote them and read this 
list! They may well work completely intuitively, but they're darned ugly, 
and look like they belong in a 60's museum of bright colours! ;)

SMSQ/E will not expand widely unless it's soothing to the eye, pleasing to 
the wrist and comfortable for the mind. And for that to happen, it will 
need a new GUI.

Let's be specific - the code that handles the windows may be fine, but the 
windows themselves really need some work. Aesthetically.

IMVVHO.

Dave

Re: [ql-users] The future of SMSQ/E


Arnould Nazarian wrote:
 One of my wishes for a long time is printing on screen with fixed size
 proportional fonts at OS level. If possible by reusing the Text87 fonts 
 because there are a lot around. That would be fast, and still 
 interesting effects could be achieved even in todays PE.

 TT told me that this would be a few hours of work and Joachim told
 that, for TT, it would be half a day's of work.

So at least one week of work for me ;-) He's of course much more
familiar with his system. Most of the time I need to invest several
hours before I can even understand what I have to do in the end.

 But TT also told me that there would immediately be some
 incompatibilities with old software, and that he doesn't want to
 take the risk of that hassle.

Yes, just changing all print routines to another layout probably isn't
a good idea.

Marcel

Re: [ql-users] The future of SMSQ/E



 I'm trying to tweak the code that is already there and do the stuff
 that just needs to be done. And I'm trying to involve you into the
 decisions I have to make as much as possible. Unfortunately not much
 feedback there so far.


OK then, so after fixed size prop fonts, what about jobs with output to 
screen not blocked if overlapped? I know that for TT freezing a job that 
has part of its window overlapped is a feature. But I don't like it, I 
would in fact prefer to have the choice at system level or even from job 
to job (with a new parameter in the EXEC command, but that would be 
harder to implement I suspect).

And then the possibility to adjust the number of slave blocks. This 
possibility (rather than radical suppression of slave blocks) would IMHO 
be inline with the philosophy of QDOS / SMSQ/E to give the choice to the 
users.

Arnould

Re: [ql-users] The future of SMSQ/E




Marcel Kilgus wrote:

 Arnould Nazarian wrote:
 
One of my wishes for a long time is printing on screen with fixed size
proportional fonts at OS level. If possible by reusing the Text87 fonts 
because there are a lot around. That would be fast, and still 
interesting effects could be achieved even in todays PE.

 Yes, just changing all print routines to another layout probably isn't
 a good idea.

It is a pity because, as I already wrote in this list a long time ago, 
QDOS was foreseen for fixed size proportional fonts, much like the 
Macintosh when it was introduced. But it was the marketing people at 
Sinclair who refused the feature, because it seemed impossible to have a 
better printing into the command line and the QDOS windows than in the 
wordprocessor (yes Quill was initially programmed for the IBM PC, and 
this machine only had fixed size fonts at the time).

This is only to stress again on the point that the routines seem to be 
foreseen for proportional printing on screen: that is why characters can 
be placed with pixel accuracy both in QDOS and the PE. So it should be 
feasible, and the main hassle would be with old QLers using old software 
that would not work as expected.

Arnould

Re: [ql-users] The future of SMSQ/E


Dexter wrote:
 The current GUIs *suck* - sorry to those who wrote them and read this
 list! They may well work completely intuitively, but they're darned ugly, 
 and look like they belong in a 60's museum of bright colours! ;)

It is mostly a problem of the limited colour choice. That's why I want
to address that problem.

And ProWesS can be brushed up, it might even be possible to give it
some 3D Look etc. Anybody can do that, the sources are there.

BTW: Thanks also for the other comments (Norman, Malcolm, Bill).

Marcel

Re: [ql-users] The future of SMSQ/E


Arnould Nazarian wrote: 
 OK then, so after fixed size prop fonts, what about jobs with output to
 screen not blocked if overlapped?

I have already thought about that but I probably can't do it. Let's
see.

 And then the possibility to adjust the number of slave blocks. This
 possibility (rather than radical suppression of slave blocks) would IMHO 
 be inline with the philosophy of QDOS / SMSQ/E to give the choice to the 
 users.

I've looked very hard into that issue. The whole slaving things is
incorporated into the SMS code like cancer. I'm not sure what to do
against it.

Marcel

Re: [ql-users] The future of SMSQ/E


Arnould Nazarian wrote: 
 This is only to stress again on the point that the routines seem to be
 foreseen for proportional printing on screen: that is why characters can 
 be placed with pixel accuracy both in QDOS and the PE. So it should be 
 feasible, and the main hassle would be with old QLers using old software 
 that would not work as expected.

It's not only old software, every software that tries to calculate the
size of a string in any way (e.g. something as simple as the button
frame) would fail (look ugly). So the system would need to distinguish
between the old and new fonts, new system routines would be needed
that calculate the width of a character/string and probably much more.

Marcel

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread ZN


On 3/12/02 at 3:44 AM Marcel Kilgus wrote:

 After the Hove show some of us went to a pub and discussed a bit about
 the future of the QL. On the drive home I talked some more with Jochen
 and in the end we decided to take the development of SMSQ/E into our
 (well, probably mainly my) hands...

[Ideas]

 WMAN still can't use the extended colours. Fortunately all WMAN routines
 and data blocks related to colour use 16 bit wide values, the upper 8
 bits are just never used. Therefore I defined a new colour format:

%   handle colour exactly like before
%0001   use lower byte as palette index
%0010   use lower byte as system palette index
%0011   use lower byte as gray scale value
%1rgb   15 bit RGB value

 The system palette is an idea found on other operating systems to give
 applications a common look.

The system palette is an excellent idea, the minor question is gow to
define it initially (defauklt values). I have my doubts about the gray
scale value palette. Perhaps a fixed color definition could be a good idea
instead, and if so, use something like the Aurora color set. It's simple
and all systems capable of 256 colors can reproduce it. That way programs
can have a unified 'shorthand' color table when needed.

Further ideas:

I have no problem with the GUI because it does not necesairly have anything
to do with WMAN. I do agree that the look is way behind the times, and the
biggest problem here is again documentation (as in lack of) that would
point to a way to change it. OTOH, a relatively limited number of
concurrent colors used in the GUI has it's advantages. I can think of MANY
things that would be on my 'most wanted list' way before a nice multicolour
3D GUI. 'Under' the GUI there has to be solid substance.

The matter of window saves using the deepest color definition regardless of
how many colors are actually used is one of the more serious, and probably
very complex issues. IMHO the MODE command still needs to have effect in
high color screen mode. Actually, ideally, the 'screen' moda nd the
'application' mode should be separate, especially now that there is
hardware with screen modes capable of concurrently showing all lesser
modes. As discussed in aprevious mail, a program using 4 colors (even if
they are from a palette of 65536) using 16BPP save areas is quite absurd,
especially as the VAST majority of programs really don't need more than a
couple simultaneous colors. I believe that the solution to this problem
also includes the solution to programs continuing to produce screen output
even when burried.

Slave blocks are a big problem. As far as I can understand, they really
need to stay in some form - with a limited number as the linear table
search is what really slows things down so imensely. Also, the real problem
in limiting the slave blocks is that the table start and length are
effectively 'hardcoded' because they are derived from pointers to other
structures. I wonder if an alternative way of limiting the number of slave
blocks would be to attack the basic area movement rules. If basic couldbe
moved along with the top of the common heap and not necesairly only when it
changes size. Although, I have a feeling that this will expose more
'hardwired' pointers :-(

Nasta

Re: [ql-users] The future of SMSQ/E


ZN wrote: 
 The system palette is an excellent idea, the minor question is gow to
 define it initially (defauklt values).

I'm planning to add them as a standard configuration block.

 I have my doubts about the gray scale value palette.

Yes, it's a bit superfluous but as it's next to no work for me to
implement I just thought go for it, especially as the main colour
for GUIs is usually gray.

 Perhaps a fixed color definition could be a good idea instead, and
 if so, use something like the Aurora color set. It's simple and all
 systems capable of 256 colors can reproduce it. That way programs
 can have a unified 'shorthand' color table when needed.

Hmm, on the one hand there's already the normal palette mode which is
well defined and I think it's unlikely that the user changes it. On
the other hand there's the 15 bit colour definition with which one can
specify exact colours. You think another 8bit fixed format would be of
any good?

 The matter of window saves using the deepest color definition regardless of
 how many colors are actually used is one of the more serious, and probably
 very complex issues.

Yes, I thought a lot about it and it is very complex. My conclusion is
that the goal is not to have applications that only use 4 colours
so that this isn't a disadvantage anymore.
This is neither nice nor elegant but pragmatical.

 IMHO the MODE command still needs to have effect in
 high color screen mode. Actually, ideally, the 'screen' moda nd the
 'application' mode should be separate, especially now that there is
 hardware with screen modes capable of concurrently showing all lesser
 modes.

I don't quite understand, which hardware can do this?

 I believe that the solution to this problem also includes the
 solution to programs continuing to produce screen output even when
 burried.

Probably, yes.

 Slave blocks are a big problem. As far as I can understand, they really
 need to stay in some form - with a limited number as the linear table
 search is what really slows things down so imensely. Also, the real problem
 in limiting the slave blocks is that the table start and length are
 effectively 'hardcoded' because they are derived from pointers to other
 structures.

Yes, exactly.

 I wonder if an alternative way of limiting the number of slave
 blocks would be to attack the basic area movement rules.

There's the Atari concept of fast memory which is not used for
slaving. Maybe I should again look into that possibility.

Marcel

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread Dexter


On Wed, 13 Mar 2002, Marcel Kilgus wrote:

  I have my doubts about the gray scale value palette.
 
 Yes, it's a bit superfluous but as it's next to no work for me to
 implement I just thought go for it, especially as the main colour
 for GUIs is usually gray.

Greyscale is actually useful. There are many cases where someone may be 
using a mono LCD panel that supports 256 grey levels.

Also, greyscale can't be beaten if you're doing mono document editing.

Dave

RE: [ql-users] The future of SMSQ/E

2002-03-12 Thread wlenerz


On 12 Mar 2002, at 15:30, Claude Mourier 00 wrote:

 I'm affraid a Ferrari waiting outside is not faster than a Mitsubishi 
 
But it looks to be waiting faster...

Wolfgang

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread wlenerz


On 12 Mar 2002, at 14:33, Marcel Kilgus wrote:

  I'm trying to tweak the code that is already there and do the stuff
 that just needs to be done. And I'm trying to involve you into the
 decisions I have to make as much as possible. Unfortunately not much
 feedback there so far.
 
 Marcel

I've kept quiet through this discussion until now. I agree with 
Marcel, that we should start with small steps - AT LEAST THEY 
WILL GET DONE!

What I'd like to do is have a look at the PE structures, to see what 
we can do with the existing code, to tweak it.

For myself, I think that the QDOSMSQ/E character (it's fast) shuld 
be kept, even if it means that we don't get another window manager.

If my memory is correct, most of the 'cosmetic' aspects (i.e. the 
window manager) are handled with vectors, whilst most of the 
underlying pointer and more basic operations are handled via traps 
(I'm simplifying here...).

Ideally, then, we could write some new vectors, most probably on 
the basic of the old ones. This would means that all old programs 
would continue to function as they are, new programs could make 
use of the facilities, if they are there.

The obvious problem there is one of copyright, because if we base 
the new vectors on the old ones, TT has his word to say. All I can 
say in this respect is that I did that once, quite some time ago, 
before the PE had timeouts in the pointer rad vector. I made a new 
vector based on the old one and a timer thing that I had written 
myelf. That actually was distributed with the first versions of FiFi (a 
thing called WLtimer). I had contacted TT, and he told me that that 
was absolutely no problem. Of course, I don't know what the 
situation would be if all of his vectors were copied but I could 
ask.

I don't have the time right now, I'll look into that this weekend.

Wolfgang

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread ZN


 I have my doubts about the gray scale value palette.

 Yes, it's a bit superfluous but as it's next to no work for me to
 implement I just thought go for it

Greyscale is actually useful. There are many cases where someone may be 
using a mono LCD panel that supports 256 grey levels.

Not really a good argument, I'm afraid. You find me a monochrome LCD
either:
a) supporting gray scale natively (not just where it says so in the
datasheet abstract!) or
b) being able to accurately show more than 16 levels of gray
and I'll concede otherwise. Just remember that once uppon a time I made LCD
controller for the QL.
Monochrome display panels are natively just that - monchrome. Gray scale
has to be emulated using FRM (Frame Rate Modulation) and/or dither. The
first works OK but only for a very low number of grays, the controller
design was mode 4 only and that was still OK. 8 would already be pushing
it.

Also, greyscale can't be beaten if you're doing mono document editing.

True. OTOH we don't have hardware capable of producing 256 levels of gray
currently (unless someone adds a new mode that would work only for QXL and
QPC) since it really implies 24 bit graphics. Now if we take into account
Marcel's good point that the ability to specify 15 bit color already
eliminates another 8-bit fixed palette, more or less the same is valid with
monochrome, as it is also a kind of fixed palette.
Unlike the system palette which is an index into a system table or the
'standard' color which also specifies stippling, more or less everything
else is covered by the 15 bit specification. Granted, Q40/60 would gain
another bit of resolution with a monochrome palette (which would
unfortunately still leave two bits unimplemented) the question being how
often monochrome is actually being used, or I should say, will beused.
However, since Marcel says it's easy to implement... I suppose one never
knows.

 The system palette is an excellent idea, the minor question is how to
 define it initially (default values).

 I'm planning to add them as a standard configuration block.

Well, you certainly have my blessings :-)
Hopefully there will be a nice utility some day to set them up while the
system is running...

 Perhaps a fixed color definition could be a good idea instead, and
 if so, use something like the Aurora color set. It's simple and all
 systems capable of 256 colors can reproduce it. That way programs
 can have a unified 'shorthand' color table when needed.

 Hmm, on the one hand there's already the normal palette mode which is
 well defined and I think it's unlikely that the user changes it.

Which one would that be? i hope we are not talking about the 256 color
system palette imposed by the PC? Or am i missing something?

 You think another 8bit fixed format would be of any good?

Actually, you are right, but I was thinking on my feet really. The proper
way to address this would be to encourage certain combinations of 15BPP
values and discourage others, as defaults. Obviously colors ommonly found
in mode 4, 8 are the ines to use, and (although not supported currently)
16, 256 definitions from Aurora - and finally 15BPP.

 The matter of window saves using the deepest color definition regardless
of
 how many colors are actually used is one of the more serious, and
probably
 very complex issues.

 Yes, I thought a lot about it and it is very complex. My conclusion is
 that the goal is not to have applications that only use 4 colours so
 that this isn't a disadvantage anymore. This is neither nice nor elegant
 but pragmatical.

If I understand it correctly, that is the same pragmatical decision used
for the high color drivers as they are. IMHO this might prove to be a
serious problem in the future given the philosophy of WMAN - simply because
the save areas increase 8-fold, the consequence of which is the speed of
their manipulation decreases by the same factor. It really undermines one
of it's best qualities: speed/simplicity. Just don't get me wrong, I don't
think this is something that needs immediate attention, I'd surely put
slave blocks on the top of that list, but let us not create another version
of the 36 character name+path limit.

 IMHO the MODE command still needs to have effect in high color screen
 mode. Actually, ideally, the 'screen' moda nd the 'application' mode
 should be separate, especially now that there is hardware with screen
 modes capable of concurrently showing all lesser modes.

 I don't quite understand, which hardware can do this?

What I meant is that hardware capable of doing 4 colors can still show the
4 colors and given proper screen drivers, 'lesser mode' applications will
still work without modification, just like they do now with the new
drivers. Apps writen for mode 4 work in 32/33 simply because the drivers
translate for them. the only thing that does not work is where there is
direct screen access, for obvious reasons, but this is really the exception
that cannot completely be catered for

Re: [ql-users] The future of SMSQ/E

2002-03-12 Thread Jerome Grimbert


ZN makes some magical things to make me read
}  I believe that the solution to this problem also includes the
}  solution to programs continuing to produce screen output even when
}  burried.
} 
}  Probably, yes.
} 
} What I mentioned in an older post. If the save areas are kept in their
} original specified format (2BPP, 4BPP, 8BPP, etc) in RAM, and the
} application always writes to the save area and in addition to that, writes
} to the screen only if it is not burried (with translation for current
} screen mode) then this solves the problem of the save area size and the
} background screen output in one stroke. Sure, at first on would get the
} 'updated' version of a window only once it gets on the top of the job
} stack, but that's certainly already a big improvement.

This might be the second step, but I would now push to let Marcel make
first the first step he wanted to do. 
His first step is the more appealing, because it would make a real visual
difference.
Non-blocking Output for program is not so visual, and I'm still too much used
to it... it might be a good second step, nevertheless.

} PS: about the 36 character limit. I know that many have argued this is
} hardly a burning problem, and for a system where all the software ever
} produced fits on an obsolete hard drve, that may largely be true. But we
} are talking about serious networking in the near future. Keep in mind that
} the trick to solving burning problems is to solve them before they become
} burning problems. This one may not be the open flame variety, but the
} ambers are being felt under the feet...

I really believe that this could be addressed with a new filesystem (Please avoid the 
kludge of M$: adding fields into previously unused part). Moreover, starting from 
nothing allow to get ride of compatibility and have things like real directory and 
symbolic links (if the designer want them...).
The traps handling names (device and filename) might need to be checked/updated for 
the supported length of the string, but there might not be such a big problem, because 
when using the old network, it has no known problem expanding the path name with N5_.
At most, existing application expected only 36 chars for filename might get broken, 
but the only one I want would be QPAC2 files. (Hint: produce a new version of it which 
would support long name and I'm happy!)
For portability sack, the new filesystem should NOT be supported by floppy or MDV or 
actual Ramdisk.
When copying from hard disk to something else a long filename, the user should specify 
the new name (automatic removal of the 'directory part' might be difficult to 
implement, or not...).

PS: and Yes, more than 4 partitions are needed (so aligning on some fdisk standard 
might also be a good thing).

Re: [ql-users] The future of SMSQ/E


??? 11/3/2002 9:44:47 ÌÌ, ?/? Marcel Kilgus [EMAIL PROTECTED] ??:

After the Hove show some of us went to a pub and discussed a bit about
the future of the QL. On the drive home I talked some more with Jochen
and in the end we decided to take the development of SMSQ/E into our
(well, probably mainly my) hands. Please no discussion about open
source etc at this point, discuss that with Tony. With the situation
as it is I'm unfortunately(!) the only one who can change anything
(related to SMSQ/E that is).

That is really exciting news indeed :-)


I have already done some stuff and before any of that gets official
I'd like to get your opinions.

We agreed that the main problem is that we have the colour drivers but
basically don't use them.

So the first thing I did was to implement the BGCOLOUR command in a
way that it doesn't need any additional memory. I thought it's
ridiculous that a simple blue (or whatever) background could take up
more than 1MB of RAM. Now it doesn't need one byte. BGIMAGE still
needs much ram but there one needs a copy of the image anyway, so
that's ok. I expect that there are no objections so far ;-)

The second problem I addressed (and I really want your input on that
one) is that WMAN still can't use the extended colours. Fortunately
large portion snipped

IMHO what should be done is to leave WMAN alone and work on an entire new PE that 
could give the QL a whole new GUI,
there all new developments and features could be implemented without sacrificing 
compatibility with older apps (since the original 
PE would still be in place). There the common look and feel as well as other 
features could be implemented from scratch neatly 
and correctly taking into account all possible QL platforms.

So far there was no point in proposing such a thing given the fact that TT wasn't 
really doing anything new and in any case wasn't 
actually listening to the users proposals etc...

There are a LOT of ideas flying around but no one with enough in-depth knowledge of 
SMSQ/E to implement them... now I think 
that gap is closed :-)


Phoebus

--
Phoebus R. Dokos - Quantum Leap Software
Web and Graphic Design - Custom Program Solutions
Tech Support - Software Localization
Web: http://www.dokos-gr.net
ICQ#:34196116 / SMS:+30973267887
SMS:[EMAIL PROTECTED]

Re: [ql-users] The future of SMSQ/E


At 10:19 PM 3/11/2002 -0500, you wrote:

IMHO what should be done is to leave WMAN alone and work on an entire new 
PE that could give the QL a whole new GUI,
there all new developments and features could be implemented without 
sacrificing compatibility with older apps (since the original
PE would still be in place). There the common look and feel as well as 
other features could be implemented from scratch neatly
and correctly taking into account all possible QL platforms.

Isn't this what ProWess is?  A whole new WMAN system with lots of features 
over the PE WMAN?

Tim Swenson

Re: [ql-users] The future of SMSQ/E


Phoebus Dokos wrote: 
 IMHO what should be done is to leave WMAN alone and work on an
 entire new PE that could give the QL a whole new GUI, there all new
 developments and features could be implemented without sacrificing
 compatibility with older apps (since the original PE would still be
 in place).

Well, I'm not going to re-invent the wheel. After all, ProWesS already
exists, it's open source and anybody can alter it the way one wants.
But unfortunately I haven't seen much progress there (I played around
with adding some 3d look and feel to it but then didn't have enough
time) and there's no reason to assume this'd be different with yet
another new window manager.

After all we won't get masses of new applications just because there's
another fancy window manager on the street. But there are quite many
existing PE applications out there which could be adapted very easily
for use with the new colours.

Marcel

Re: [ql-users] The future of SMSQ/E


At 10:22 ÌÌ 11/3/2002, you wrote:

At 10:19 PM 3/11/2002 -0500, you wrote:

IMHO what should be done is to leave WMAN alone and work on an entire new 
PE that could give the QL a whole new GUI,
there all new developments and features could be implemented without 
sacrificing compatibility with older apps (since the original
PE would still be in place). There the common look and feel as well as 
other features could be implemented from scratch neatly
and correctly taking into account all possible QL platforms.

Isn't this what ProWess is?  A whole new WMAN system with lots of features 
over the PE WMAN?

Tim Swenson

Not really...

First of all, ProWesS is depended upon the PE for many things, second it's 
insanely slow (esp. on regular QL systems) where regular PE is blazingly 
fast (IMHO the difference of assembly over C - even compiled with gcc-qdos 
ProWesS apps are very slow compared to regular PE apps which literally fly!).

Many features of ProWesS could (and should) be implemented in a new Gui 
(eg. the Vector fonts, virtual screens) and the common look and feel that 
ProWesS provides is a must...

However again a SMSQ/E bundled new Gui could have other significant 
advantages like:

1. Being really a part of the OS ever present and without memory loss
2. Extremely fast.
3. Being able to provide a TRUE desktop where now we have a patchwork of a 
quasi GUI routines and pseudo graphics.
etc...


Phoebus

Re: [ql-users] The future of SMSQ/E


??? 11/3/2002 10:27:12 ÌÌ, ?/? Marcel Kilgus [EMAIL PROTECTED] ??:

Phoebus Dokos wrote: 
 IMHO what should be done is to leave WMAN alone and work on an
 entire new PE that could give the QL a whole new GUI, there all new
 developments and features could be implemented without sacrificing
 compatibility with older apps (since the original PE would still be
 in place).

Well, I'm not going to re-invent the wheel. After all, ProWesS already
exists, it's open source and anybody can alter it the way one wants.
But unfortunately I haven't seen much progress there (I played around
with adding some 3d look and feel to it but then didn't have enough
time) and there's no reason to assume this'd be different with yet
another new window manager.

After all we won't get masses of new applications just because there's
another fancy window manager on the street. But there are quite many
existing PE applications out there which could be adapted very easily
for use with the new colours.

Marcel

True too, but I still believe that a new GUI would be the right way to go (that 
doesn't prohibit you from adding the support for older 
PE apps of course).

However (and this requires a lot of discussion), you could assemble a team of people 
that COULD design a new PE and you could 
incorporate it into SMS... moreover something like that with your input as the main 
SMSQ developer could be made faster and a lot 
better than what we have now...



--
Phoebus R. Dokos - Quantum Leap Software
Web and Graphic Design - Custom Program Solutions
Tech Support - Software Localization
Web: http://www.dokos-gr.net
ICQ#:34196116 / SMS:+30973267887
SMS:[EMAIL PROTECTED]

Re: [ql-users] The future of SMSQ/E


Timothy Swenson wrote: 
 I did a quick scan on what you are proposing.  My main concern is to make
 sure that any PE program compiled to use the new WMAN and colors will still 
 run with the older WMAN.  I'm assuming that the older WMAN ignored part of 
 the 16-bit color word and will continue to do this.

It is perhaps possible to do applications that look ok in both modes
(by using different colour values). But in my opinion it's either use
the new colours or stay with only 4 forever. I'm trying to remove all
hassles the 16bit colour mode brings (still investigating the slaving
stuff for example) so that in the end one can decide to use the new
mode and only the new mode without having to regret it.

 As for colors in general, I don't use them other to view JPG's ( and
 don't really look at them too much on the Q40).

You're satisfied with 512x256 as resolution? Wow, that's about the
size of a bunch of icons on my screen ;-)

 I would encourage you to work on documenting areas of SMSQ/E that
 are sparsely documented.

Not my strong side. I can try to find out anything that is unclear but
I'm not much into the documentation thing. Feel free to ask.

Marcel

Re: [ql-users] The future of SMSQ/E


??? 11/3/2002 10:27:12 ÌÌ, ?/? Marcel Kilgus [EMAIL PROTECTED] ??:
Well, I'm not going to re-invent the wheel. After all, ProWesS already
exists, it's open source and anybody can alter it the way one wants.
But unfortunately I haven't seen much progress there (I played around
with adding some 3d look and feel to it but then didn't have enough
time) and there's no reason to assume this'd be different with yet
another new window manager.


Again, ProWesS cannot be made faster if its not written in Assembler really and if you 
are going to do that, why can't we take the 
best of everything, package it in a real desktop, add some spices and put it INSIDE 
SMSQ??? :-)


After all we won't get masses of new applications just because there's
another fancy window manager on the street. But there are quite many
existing PE applications out there which could be adapted very easily
for use with the new colours.

Marcel

To add something else here, we won't get masses of new applications because of a fancy 
Window manager yes...
but we will get them if that window manager is VERY fast and easy to program 
(Menu_Rext  easy :-)

--
Phoebus R. Dokos - Quantum Leap Software
Web and Graphic Design - Custom Program Solutions
Tech Support - Software Localization
Web: http://www.dokos-gr.net
ICQ#:34196116 / SMS:+30973267887
SMS:[EMAIL PROTECTED]

Re: [ql-users] The future of SMSQ/E


At 04:36 AM 3/12/2002 +0100, you wrote:

You're satisfied with 512x256 as resolution? Wow, that's about the
size of a bunch of icons on my screen ;-)

I don't use a desktop on the QL and really don't see a major need for a 
desktop.  I use them at work (IRIX, Linux, Windows) and find them 
moderately usefull.

For the QL, I find Qascade fits my need to fire off programs.  Anyhow, I 
feel a GUI is just there for me to open more shells :-).

Tim Swenson

Re: [ql-users] The future of SMSQ/E


At 10:42 ÌÌ 11/3/2002, you wrote:

At 04:36 AM 3/12/2002 +0100, you wrote:

You're satisfied with 512x256 as resolution? Wow, that's about the
size of a bunch of icons on my screen ;-)

I don't use a desktop on the QL and really don't see a major need for a 
desktop.  I use them at work (IRIX, Linux, Windows) and find them 
moderately usefull.

For the QL, I find Qascade fits my need to fire off programs.  Anyhow, I 
feel a GUI is just there for me to open more shells :-).

Tim Swenson

Tim,
A real desktop and a standard Look and Feel are required for modern 
computing platforms, it's both useful from an aesthetic view and from a 
usability point... Browsers, gfx programs... why don't we have these things 
on a QL? Ever tried to write something like that? I am currently and it's a 
real pain as the OS doesn't help at all, ProWesS could be of real help due 
to it's nice connectivity with its API but it's slow therefore 
impractical...


Phoebus

Re: [ql-users] The future of SMSQ/E


Phoebus Dokos wrote: 
 Again, ProWesS cannot be made faster if its not written in Assembler
 really and if you are going to do that,

Nobody is going to do that. That's basically the point. We don't have
enough developers.

 why can't we take the best of everything, package it in a real
 desktop, add some spices and put it INSIDE SMSQ??? :-)

You're volunteering? ;-) But frankly I have no clue what's the
advantage of having the GUI inside SMSQ. I think you can easily make
a module out of ProWesS and put it into the SMSQE file, but why
bother?

 To add something else here, we won't get masses of new applications
 because of a fancy Window manager yes... but we will get them if
 that window manager is VERY fast and easy to program (Menu_Rext easy
 :-)

You're still dreaming that a GUI that looks better than the PE can be
as fast as the PE...

Marcel

Re: [ql-users] The future of SMSQ/E


At 10:48 ÌÌ 11/3/2002, you wrote:

Phoebus Dokos wrote:


You're still dreaming that a GUI that looks better than the PE can be
as fast as the PE...

I wouldn't consider it a dream. I have done something simple enough like PE 
but completely graphical (and IMVVVHO a lot more beautiful) -It actually 
looks like the BeOs GUI) and my windows in S*BASIC (even interpreted) 
opened up almost as fast as PE ones. I could continue working on that but I 
stumbled upon the scheduler part :-)
In order to work with something like that you need a level of access to the 
OS that I 1. Don't master, 2. Don't have from working from the outside

As for the fonts you are right, however it could be corrected by using 
the bitmap screen font / scalable output font approach...
and don't forget the ArmQL coming out soon :-) (Especially the XScale 
version using as core emulation engine uQLx could easily outperform both 
QPC2 and Q60) (Or at least that's what preliminary test have shown Dave 
IIRC :-)


Phoebus

Re: [ql-users] The future of SMSQ/E


Phoebus Dokos wrote: 
 and don't forget the ArmQL coming out soon :-) (Especially the XScale
 version using as core emulation engine uQLx could easily outperform both 
 QPC2 and Q60) (Or at least that's what preliminary test have shown Dave 
 IIRC :-)

Well, regarding that:

a) why should an Arm based uQLx be faster than an x86 based uQLx? x86
is approaching the 3GHz frontier.

b) I can tell you that there aren't thousands of QPC users out there
and even less Qx0 users, so how big could a potential ArmQL user base
be in the end? I say that a value with 3 digits is already a big goal.

OK, finally off to bed, Marcel

Re: [ql-users] The future of SMSQ/E


At 11:09 ÌÌ 11/3/2002, you wrote:

Phoebus Dokos wrote:
  and don't forget the ArmQL coming out soon :-) (Especially the XScale
  version using as core emulation engine uQLx could easily outperform both
  QPC2 and Q60) (Or at least that's what preliminary test have shown Dave
  IIRC :-)

Well, regarding that:

a) why should an Arm based uQLx be faster than an x86 based uQLx? x86
is approaching the 3GHz frontier.

Because ARM IS faster (and with X-Scale's at 1 GHz coming up I don't even 
THINK that a 2 GHz can come close)

b) I can tell you that there aren't thousands of QPC users out there
and even less Qx0 users, so how big could a potential ArmQL user base
be in the end? I say that a value with 3 digits is already a big goal.

Not really because due to its platform the ArmQL CAN be used as a QL but 
not only for that, it can run RiscOS, Linux / Net(Open) BSD and even PalmOS 
:-) (V. 5 and above)... and with a potential for handheld operation as well 
:-) (Or industrial apps etc. etc. etc...)



OK, finally off to bed, Marcel


G'night!


---
Incoming mail is certified Virus Free. Ôï åéóåñ÷üìåíï ìÞíõìá åßíáé 
åëåýèåñï éþí.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.333 / Virus Database: 187 - Release Date: 8/3/2002

Re: [ql-users] The future of SMSQ/E


Windows was successful not because of the desktop, but because it was based 
on MS-DOS, the winner of the desktop OS wars.  Back when the PC first came 
out there where three reasons to by the IBM PC; I, B, and M.  IBM validated 
the PC for business use.  By the time Windows came out, the only competitor 
was Apple, and they were always priced higher.

Popular does not always mean better. Betamax was technologically better 
than VHS, but VHS won the marketing battle.

I don't want to use an OS designed for the average person, who still has 
problems getting the VCR to stop flashing 12:00.

I have no interest in marketing SMSQ/E to the outside world.  I find it 
great for my own purposes and I leave it at that.  If I had my own company, 
I would probably use 100% Linux.  I prefer SMSQ/E for my personal computer 
and personal programming.

It is my opinion that future of the QL should be aimed squarely at the 
present users will very little consideration to expending to new 
users.  Yes, I would like to get some old QL users back into the fold, but 
I don't think we'll be able to convert Win2K or Linux users.

Point-and-click is OK for some things, but I find I can get files copied 
faster with a shell than by using two GUI file browsers and dragging and 
dropping between them, esp. for mass copying.  Luckily I learned touch 
typing years back in High School and I use it every day. The only problem I 
have is typing copy file_txt instead of cp file_txt when I'm at 
work.  I also find moving my right hand from the keyboard to the mouse, and 
back again, can slow things down.  I've seen a real good Win2K person doing 
everything to administer a server without touching the mouse.

Remember, this is only my personal opinion.  I feel that it is SMSQ/E that 
I have the most to help control the future of and so I want to get as much 
input as I can.  There is no way I can influence the direction of Linux or 
Unix in general.

Tim Swenson

Re: [ql-users] The future of SMSQ/E

At 11:43 ÌÌ 11/3/2002, you wrote:

Windows was successful not because of the desktop, but because it was
based on MS-DOS, the winner of the desktop OS wars. Back when the PC
first came out there where three reasons to by the IBM PC; I, B, and
M. IBM validated the PC for business use. By the time Windows came out,
the only competitor was Apple, and they were always priced higher.

Popular does not always mean better. Betamax was technologically better
than VHS, but VHS won the marketing battle.

I don't want to use an OS designed for the average person, who still has
problems getting the VCR to stop flashing 12:00.

I have no interest in marketing SMSQ/E to the outside world. I find it
great for my own purposes and I leave it at that. If I had my own
company, I would probably use 100% Linux. I prefer SMSQ/E for my personal
computer and personal programming.

It is my opinion that future of the QL should be aimed squarely at the
present users will very little consideration to expending to new
users. Yes, I would like to get some old QL users back into the fold, but
I don't think we'll be able to convert Win2K or Linux users.

In that case as we Greeks say, lets close shop then and bury the dead
before it rots. If it's geared towards current users then you need nothing
more theoretically and you also will run out of users sometime...soon. So
how are you proposing on developing if we are not willing to fund the
current developer and not willing to let outside developers get i?. In that
case honestly it would be best for toying around for my programming to get
BBC Basic for the PC (just because it reminds me S*Basic) and never look
back. Is that the way to go? What is the point of existence of ANYTHING if
it is stagnant. (Notorious example Byzantium :-) Terminate development and
push away new users and you are all done so let's shoot the horse in
advance so it won't suffer...

Point-and-click is OK for some things, but I find I can get files copied
faster with a shell than by using two GUI file browsers and dragging and
dropping between them, esp. for mass copying. Luckily I learned touch
typing years back in High School and I use it every day. The only problem
I have is typing copy file_txt instead of cp file_txt when I'm at
work. I also find moving my right hand from the keyboard to the mouse,
and back again, can slow things down. I've seen a real good Win2K person
doing everything to administer a server without touching the mouse.

I do it myself, however try to do CTRL-A then CTRL-C then CTRL-TAB to the
new window and CTRL-V and you copied hundreds of files for fun :-) (Still
through the Desktop though even without touching the mouse) (Oh and touch
typing doesn't help at all with the underscore being where it is... not to
mention the lack of really intelligent wildcards)

Remember, this is only my personal opinion. I feel that it is SMSQ/E that
I have the most to help control the future of and so I want to get as much
input as I can. There is no way I can influence the direction of Linux or
Unix in general.

The problem is that you are referring to the past (no offense intended
here... it's only mh and totally personal o :-)) and not the future. The
past is gone, long live the future and again IMHO I do prefer a QL in my
future than no QL in my future :-)

Tim Swenson

---
Incoming mail is certified Virus Free. Ôï åéóåñ÷üìåíï ìÞíõìá åßíáé
åëåýèåñï éþí.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.333 / Virus Database: 187 - Release Date: 8/3/2002

Re: [ql-users] The future of SMSQ/E