Re: [Ql-Users] Fwd: Re: Theme file format

[Per Witte via Ql-Users]

As mentioned, the suggested binary standard would be in addition to the
established text standard as used by QCoCo. Its easy enough to convert
files back and forth between these formats. So pundits and punters are free
to choose. A possible advantage with having a header, such as "THB9" (where
9 = chr$(57)) would be so that when one VIEWs a file with the _thb
extension one can easily see what kind of file it is, However, a headerless
file would be the simplest, as one could then just:

thl = FLEN(\themefile$)
tha = ALCHP(thl)
LBYTES themefile$, tha
SP_JOBOWNPAL -1, tha

Should a standard palette at some point contain 58 or 102 entries, it would
still load alright and, presumably Wman would know what to do with it. If
one were to load an old, 57 entry theme file by mistake, the program
wouldnt crash or anything, just display some weird colours.

> <> why not have a standard
> theme file that can be edited with MenuConfig. One could probably have
> the "SCLx" extension, which would give you enough options to play
withedit
> (SCL0-9, SCLA-Z, SCLa-z). Of course, parsing that would be even more
> difficult.

To me it would make more sense to use Config to select one of a number of
predefined themes, rather than use it to edit the themes themselves, which
is a design, rather than a configuration problem. We've got the excellent
QCoCo for that.

Per



On 14 November 2017 at 13:01, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> Hi,
>
> >> Theme file format...
> >> Rethorical question: Is it worthwhile to create a new
> >> format to save some space (a few bytes, I suppose)
> >> when we have (QPC2, SMSQmulator)  128MB at our disposal?
>
> It's the typical chicken-and-egg problem - if you don't have any
> standard, nobody is (ever) going to use it. If you create a standard
> now, nobody is currently using it (exept perhaps some in-house
> productions) - but somebody **might** in the future.
> You will not be worse off with the latter, but maybe better.
>
>
>
> > Despite computers getting ever faster and bigger, the likes of
> > Windoze still seem slow at times, and just as soon run out of space -
> > as they always did.. That may partly be down to BLOAT and lazyness.
>
> Or to legibility. I'd personally prefer a text file - because it is text
> and you can alter it with a simple text editor which is generally faster
> than using spmething like wined to edit the bianry file directly.
> Granted, you can also totally muck it up by merrily editing the file
> beyong all recognition, but -to me- that would be a small price to pay.
>
>
> > In the case of the "QL", software might be expected to run on a wide
> > variety of platforms, some fast and big, some slow and tight. IMHO,
> > efficiency is rarely a bad thing unless achieving it is considerably
> > more costly that what it is likely to save.
>
> True. On the other hand, a program would normally only do that when
> starting up and the time taken to parse the palette file, compared to
> the time taken to start up, would probably not be very important.
>
> > To load a palette (theme) youd use something like:
> > ..
> > FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
> >  INPUT#ch; it$
> >  POKE_W addr + ofs, HEX(it$(2 to))
> >
> > Whats not to improve? ;)
> >
>
> Actually, I would prefer:
> 00 : $200
> 01 : $ff00
>
> etc
>
> Thay way, I'd know right away what to edit.
>
> > I propose to use a binary format (see below) and use LBYTES instead.
>
> The debate of plain text config files (large, take a while to process)
> vs binary files (unreadable to us normal humans) isn't new...
>
> > This cuts space and time, and would allow a number of such files to
> > be concatenated.
>
> You could also concatenate text files.
>
> > But instead of LBYTESing any kind of rubbish, I
> > suggested we make a header that would give a strong indication, if
> > not absolute certainty, that we were loading the right kind of file.
>
> Oh, if you want something standard, a header is definitely needed. A
> program could perfectly well only use the first 30 or so of the colours
> and have a theme file only for those. One would need to know honw many
> colurs are un that aplette file. I do notice that your proposal seems to
> have the number of colours (after the "THM")?
>
> >> In fact, a complete palette should have 58 entries.
> >> The original author forgot to reserve a slot for the
> >> border of the error window. Doesn’t a new format imply
> >> a rewrite of existing programs?
>
> Not unless they want to use the new format. As I said above, if they
> don't use it, you're not worse off than now.
>
> >
> >> Why not create a new type of file? I would suggest type
> >> 84 (T for theme).
> > File types are sadly not much supported in QL land. Defining a new file
> > type could cause problems - for existing file managment programs, for
> > example.
>
> A certin number of prowess progs have a different filetype if I'm not
> mistaken. The problem here is that, apart from maybe being a 

[Ql-Users] QL/E version 3.17 (Edition 1710, Codename "Liberated", last updated 30.10.2017) is out now.

[Urs Koenig (QL) via Ql-Users]

Some highlights:
- Support for Q68 platform added
- Auto-positioning of QDT desktop icons at boot-up
- Liberation Software packages Q_Liberator, QLOAD, QREF and RPM added
- Updated Photon and new PHoton General ToolKit (PHGTK) added
- Latest IP Network Device Driver and SERNET added
- DISA and QMAKE added
- More benchmark programs added

Plus many updates and improvements here and there.

Get it from the link in the message footer.

QL forever!

Cheers, Urs

http://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
http://www.youtube.com/QLvsJAGUAR
https://plus.google.com/+QLvsJAGUAR
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE & more
Videos, pictures & information

___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

[Jan Bredenbeek via Ql-Users]

On 14 November 2017 at 13:03, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> yes Jochen told me on sundcay that it's OK to be distributed.
>

Great, now I can finally convert my programs to use the QL config standard
rather than having to write my own :).
(I've always found the user interface of the standard config program a bit
awkward to use...).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

[Wolfgang Lenerz via Ql-Users]

Hi,

yes Jochen told me on sundcay that it's OK to be distributed.

Wolfgang
> 
> I'm wondering whether menuconfig is now freeware or not. According to this
> thread http://qlforum.co.uk/viewtopic.php?t=1025 it is still commercial
> software by Jochen Merz. Does anyone have an idea?
> 
> Jan.
> 
___
QL-Users Mailing List

[Ql-Users] Fwd: Re: Theme file format

[Wolfgang Lenerz via Ql-Users]

Hi,

>> Theme file format...
>> Rethorical question: Is it worthwhile to create a new
>> format to save some space (a few bytes, I suppose)
>> when we have (QPC2, SMSQmulator)  128MB at our disposal?

It's the typical chicken-and-egg problem - if you don't have any
standard, nobody is (ever) going to use it. If you create a standard
now, nobody is currently using it (exept perhaps some in-house
productions) - but somebody **might** in the future.
You will not be worse off with the latter, but maybe better.



> Despite computers getting ever faster and bigger, the likes of
> Windoze still seem slow at times, and just as soon run out of space -
> as they always did.. That may partly be down to BLOAT and lazyness.

Or to legibility. I'd personally prefer a text file - because it is text
and you can alter it with a simple text editor which is generally faster
than using spmething like wined to edit the bianry file directly.
Granted, you can also totally muck it up by merrily editing the file
beyong all recognition, but -to me- that would be a small price to pay.


> In the case of the "QL", software might be expected to run on a wide
> variety of platforms, some fast and big, some slow and tight. IMHO,
> efficiency is rarely a bad thing unless achieving it is considerably
> more costly that what it is likely to save.

True. On the other hand, a program would normally only do that when
starting up and the time taken to parse the palette file, compared to
the time taken to start up, would probably not be very important.

> To load a palette (theme) youd use something like:
> ..
> FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
>  INPUT#ch; it$
>  POKE_W addr + ofs, HEX(it$(2 to))
> 
> Whats not to improve? ;)
>

Actually, I would prefer:
00 : $200
01 : $ff00

etc

Thay way, I'd know right away what to edit.

> I propose to use a binary format (see below) and use LBYTES instead.

The debate of plain text config files (large, take a while to process)
vs binary files (unreadable to us normal humans) isn't new...

> This cuts space and time, and would allow a number of such files to
> be concatenated. 

You could also concatenate text files.

> But instead of LBYTESing any kind of rubbish, I
> suggested we make a header that would give a strong indication, if
> not absolute certainty, that we were loading the right kind of file.

Oh, if you want something standard, a header is definitely needed. A
program could perfectly well only use the first 30 or so of the colours
and have a theme file only for those. One would need to know honw many
colurs are un that aplette file. I do notice that your proposal seems to
have the number of colours (after the "THM")?

>> In fact, a complete palette should have 58 entries.
>> The original author forgot to reserve a slot for the
>> border of the error window. Doesn’t a new format imply
>> a rewrite of existing programs?

Not unless they want to use the new format. As I said above, if they
don't use it, you're not worse off than now.

> 
>> Why not create a new type of file? I would suggest type
>> 84 (T for theme).
> File types are sadly not much supported in QL land. Defining a new file
> type could cause problems - for existing file managment programs, for
> example.

A certin number of prowess progs have a different filetype if I'm not
mistaken. The problem here is that, apart from maybe being a pain in the
neck for filemanagers, nobody notices them. Chicken-and-egg again. Same
reasoning may apply.

> to try to prevent a third and a fourth "standard" to emerge (unnecessary
> creating confusion and nonsense), by engaging anyone who has an
> opinion to "speak now or be forever silent" (as they say at the wedding
> ceremony in the C of E.) As mentioned, the file will be binary, but I
> describe it here in assembler for clarity:
> 

Well if one goes with a binary format, and to put the fox amongst the
chickens (what's it with me and chickens today?) why not have a standard
theme file that can be edited with MenuConfig. One could probably have
the "SCLx" extension, which would give you enough options to play with
(SCL0-9, SCLA-Z, SCLa-z). Of course, parsing that would be even more
difficult.

Regards

Wolfgang
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

[Ralf Reköndt via Ql-Users]

So you need a commercial program to configure a free OS?


-Original-Nachricht-
Betreff: Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure
Datum: 2017-11-14T11:33:11+0100
Von: "Jan Bredenbeek via Ql-Users" 
An: "ql-us...@q-v-d.com" 

On 13 November 2017 at 18:27, Peter Graf via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Duncan,
>
> > the version of menuconfig I have is 3.36 and is dated 2003.
>
> Thank you. That's it! :) With menuconfig 3.36 it worked.
>
> > The version of menuconfig on Dilwyn's site is 3.34
>
> Found even 3.36 when I searched again. Maybe it is stored at more than
> one location.
>

I'm wondering whether menuconfig is now freeware or not. According to this
thread http://qlforum.co.uk/viewtopic.php?t=1025 it is still commercial
software by Jochen Merz. Does anyone have an idea?

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Theme file format

[François Van Emelen via Ql-Users]

Op 13/11/2017 om 17:59 schreef Per Witte via Ql-Users:


Thanks for your reply  explanation.

François Van Emelen


___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

[Giorgio Garabello via Ql-Users]

>
>
> I'm wondering whether menuconfig is now freeware or not. According to this
> thread http://qlforum.co.uk/viewtopic.php?t=1025 it is still commercial
> software by Jochen Merz. Does anyone have an idea?


menuconfig336.zip  (30K)
- Level 2 MenuConfig program v3,36, needs PE and Menu Extension [13/11/17]

from Dilwyn site.

Giorgio
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

[Jan Bredenbeek via Ql-Users]

On 13 November 2017 at 18:27, Peter Graf via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Duncan,
>
> > the version of menuconfig I have is 3.36 and is dated 2003.
>
> Thank you. That's it! :) With menuconfig 3.36 it worked.
>
> > The version of menuconfig on Dilwyn's site is 3.34
>
> Found even 3.36 when I searched again. Maybe it is stored at more than
> one location.
>

I'm wondering whether menuconfig is now freeware or not. According to this
thread http://qlforum.co.uk/viewtopic.php?t=1025 it is still commercial
software by Jochen Merz. Does anyone have an idea?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] Theme file format

[Per Witte via Ql-Users]

Sorry, that was supposed to be:

header
dc.b "THB",57;  not "THM",57
data
dc.w $200
dc.w $FFC0
etc..

On 13 November 2017 at 17:59, Per Witte  wrote:

> > Theme file format
> > I had a look at Theme file format on QL forum. Some
> > comments and questions:
> >
> > Rethorical question: Is it worthwhile to create a new
> > format to save some space (a few bytes, I suppose)
> > when we have (QPC2, SMSQmulator)  128MB at our disposal?
> Despite computers getting ever faster and bigger, the likes of
> Windoze still seem slow at times, and just as soon run out of space -
> as they always did.. That may partly be down to BLOAT and lazyness.
>
> In the case of the "QL", software might be expected to run on a wide
> variety of platforms, some fast and big, some slow and tight. IMHO,
> efficiency is rarely a bad thing unless achieving it is considerably
> more costly that what it is likely to save.
>
> I dont know where the current theme file format originated, but a few
> programs use that. It is sometimes (usually?) given the extension
> _thm. It is a pure text file that looks like this:
>
> $200
> $FFC0
> .. etc altogether 57 lines
>
> To load a palette (theme) youd use something like:
> ..
> FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
>  INPUT#ch; it$
>  POKE_W addr + ofs, HEX(it$(2 to))
>
> Whats not to improve? ;)
>
> I propose to use a binary format (see below) and use LBYTES instead.
> This cuts space and time, and would allow a number of such files to
> be concatenated. But instead of LBYTESing any kind of rubbish, I
> suggested we make a header that would give a strong indication, if
> not absolute certainty, that we were loading the right kind of file.
>
> A number of file formats on the QL scene dont have headers, and this
> sometimes causes confusion not to mention frustration and the
> potential for inelegant crashes unless preventive steps are taken by
> each and every program using them. The _scn extension, for example
> means widely different things..
>
> > Not all palette files have 57 entries.
> Well, thats the current tally, as given by the Wman2 function
> SP_GETCOUNT. If that were to change, a file header might help to
> identify that fact quickly.
>
> > In fact, a complete palette should have 58 entries.
> > The original author forgot to reserve a slot for the
> > border of the error window. Doesn’t a new format imply
> > a rewrite of existing programs?
> No.
>
> > Will Qspread, QD, Files,... comply?
> I dont think any of them load external palettes. If they do, they
> will no doubt happily continue to use whatever standard theyre
> using now.
>
> > Afraid of having 57 entries filled with wrong data?
> Not afraid, as loading the wrong data will not crash the program,
> only display strange colours. POKEing or LBYTESing more data than
> ALCHPed would be seriously problematic.
>
> > Why not create a new type of file? I would suggest type
> > 84 (T for theme).
> File types are sadly not much supported in QL land. Defining a new file
> type could cause problems - for existing file managment programs, for
> example.
>
> > Just my two cents.
> Glad for your interest so this matter can be finalised.
>
> The current suggestion is for theme files to have an additional
> format to the existing one. It will be dead easy to convert theme
> files between "standards", so programmers can choose to support the
> new standard (if it becomes one) - or not. The reason Im bringing this up
> is
> to try to prevent a third and a fourth "standard" to emerge (unnecessary
> creating confusion and nonsense), by engaging anyone who has an
> opinion to "speak now or be forever silent" (as they say at the wedding
> ceremony in the C of E.) As mentioned, the file will be binary, but I
> describe it here in assembler for clarity:
>
> header
> dc.b "THM",57
> data
> dc.w $200
> dc.w $FFC0
> etc..
>
> Other suggestions have been made. This is V3.0, currently my
> preferred option, but Im open to improvements, including a header-less
> binary, considered earlier on.
>
> Per
>
> On 13 November 2017 at 15:50, François Van Emelen via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
>
>> Hi,
>>
>> Theme file format
>> I had a look at Theme file format on QL forum.
>> Some comments and questions:
>>
>> Rethorical question: Is it worthwhile to create a new format to save some
>> space (a few bytes, I suppose) when we have (QPC2, SMSQmulator)  128MB at
>> our disposal?
>> Not all palette files have 57 entries.
>> In fact, a complete palette should have 58 entries. The original author
>> forgot to reserve a slot for the border of the error window.
>> Doesn’t a new format imply a rewrite of existing programs?
>> Will Qspread, QD, Files,... comply?
>> Afraid of having 57 entries filled with wrong data? Why not create a new
>> type of file? I would suggest type 84 (T for theme).
>> Just my two cents.
>>
>> Have a nice day.
>>
>> François Van Emelen
>>
>>
>>
>>