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 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 _______________________________________________ QL-Users Mailing List
