As for the ability to be more user friendly, I think the whole thing proves
itself... The fact that many QLers have moved from QPC1 to QPC 2 proves
that if someone is given the choice, they go for the extra colours and the
useless features of Windoze.
I do not agree. I don't know exactly how
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.
As I mentioned before with the reverse approach I suggest, this should not
be too
And the idea of having accelerated ProWesS
drivers etc. has been in my head for a long time, too.
Well Marcel, this could be done if you allow switching between native code
and back. Then recompile ProWesS with some glue code and...
If we first handle the screen update thingies I suggest, we
In Dave's Party Busting Very Very Humble Opinion ;) -
The current GUIs *suck*
For a view on the aesthetic development of GUI's from someone outside(?) our
community have a look at -
www.overclockingopolis.co.uk/win101.shtml
John in Wales
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
-
-Original Message-
From: John G Hitchcock [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 11:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [ql-users] The future of SMSQ/E
In Dave's Party Busting
What we need is a tool or something that help developpers/users to
use more
colours.
Claude
Exactly. Tools like Easyptr to help BASIC and C programmers. Did QPTR
Toolkit get updated for GD2 at all?
--
Dilwyn Jones
[EMAIL PROTECTED]
http://www.soft.net.uk/dj/index.html
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
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
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
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.
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
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
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
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
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
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
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
: [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
[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
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
??? 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
??? 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
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
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
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
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
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
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
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
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
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
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
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
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
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...
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
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
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
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
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
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
}
??? 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
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
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
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
??? 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
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
??? 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
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
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,
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,
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
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
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,
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
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
Hmm, I think you misunderstood what I was getting at.
1. I see very few chances of getting new folks to the QL. This is not a
bad thing, just reality.
2. I would like to see further development for the QL world. The recent
developments for TCP/IP and CD access are prime examples of what
57 matches
Mail list logo
