Re: [Ql-Users] QD 2018 colours
Op Wed, 29 Aug 2018 00:48:26 +0200 schreef Marcel Kilgus via Ql-Users : Bob Spelten via Ql-Users wrote: But setting a custom width, moving the "size" to the left, is where the right side also moves left. OK, now I see what you mean. The size is incremented in 20 character steps. There is no explanation in the code why that is, but as this is the same amount that is used when the edit window is panned I guess that this is the reason. I tried removing the restriction and most things seemed to work, but I found at least a minor bug, so I'm not comfortable lifting that restriction. I can make the bottom right corner stay in place, though. The downside is that now when you resize less than 20 characters more basically nothing happens at all, this might be confusing for some users. Jochen once explained that size grows in discrete steps but I would expect the right side to be anchored, now full screen can never be reached. Ususally it cannot be reached because the maximum line length is exhausted before the maximum screen width. OK, this is indeed the case when set to 160 characters on a 1024 display. Leaving it anchored right and restricting left movement would then be preferable. My numberless Basic is named xxx_bsl so would not benefit. Usually I start QD through FI2 where the right command flag is added to take care of this. I start 100 QDs when working on stuff like this, 10% by hotkey and 90% by FiFi ;) Just one more. It sometimes happens when a line is longer than the window and I use ALT-right to jump to the end of the line, the text pans less than needed but the cursor/arrow lands on the right spot, outside the window. This seems more likely to happen when the cursor is already at position 80+. Can't reproduce right now. And in any case, this is a problem with the editor core, which I'm not touching with a 10 feet pole. Last one? Opening QD in read-only mode (\P) lets me pick a block for the scrap but using ^Z to hot-buffer one line is not working. A bug or a missed feature? Apparently you have to thank me that CTRL+X works in this mode: cmp.b #24,d1 ; CTRL X => Quit beq.s not_protected ; yes, so do it (Marcel wants it !!) I added cmp.b #26,d1 ; CTRL Z => Mark current line beq.s not_protected ; yes, so do it (Bob wants it !!) Thanks again Marcel for looking into these points and for including my name in the source. Now I have no choice in calling it my favourite editor. Bob -- The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/; --- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
On 29/08/2018 00:53, Marcel Kilgus via Ql-Users wrote: pjwitte via Ql-Users wrote: So that wouldnt help you, Bob. In VB0.3 the behaviour changed again. Now DOing the resize button annoyingly resets the width to 80 coloumns for some reason as well as maxing the hight. It has never worked for me before, but I fixed it anyway, Great! :) There is one serious bug though, that I hope will one day be tackled by some brave and patient soul. Tried. Failed. Not happening, sorry. Its hard to demonstrate and almost impossible to catch in the act. That's basically the problem. That and that the editor core is thousands of lines of hard to read code. But if you can ever repro it... Ill have another go at trying to reproduce it. But itll take time, so dont hold yer breath ;) Thanks for all youve done so far! :) Per ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
On 29/08/2018 00:48, Marcel Kilgus via Ql-Users wrote: Bob Spelten via Ql-Users wrote: But setting a custom width, moving the "size" to the left, is where the right side also moves left. OK, now I see what you mean. The size is incremented in 20 character steps. There is no explanation in the code why that is, but as this is the same amount that is used when the edit window is panned I guess that this is the reason. I tried removing the restriction and most things seemed to work, but I found at least a minor bug, so I'm not comfortable lifting that restriction. I can make the bottom right corner stay in place, though. The downside is that now when you resize less than 20 characters more basically nothing happens at all, this might be confusing for some users. A possible compromise might be to round up? If the user indicates he wants to resize by managing to move the resize sprite more than half way to the next size increment, that is taken as a valid resize request (provided there is room enough). Just a thought.. Jochen once explained that size grows in discrete steps but I would expect the right side to be anchored, now full screen can never be reached. Ususally it cannot be reached because the maximum line length is exhausted before the maximum screen width. Im not sure I understand what you mean here. QD comes pre-configured for a maximum line length of 160 char, so that should allow for a window width of at least 960 pixels <> Per ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
pjwitte via Ql-Users wrote: > So that wouldnt help you, Bob. In VB0.3 the behaviour > changed again. Now DOing the resize button annoyingly resets the width > to 80 coloumns for some reason as well as maxing the hight. It has never worked for me before, but I fixed it anyway, > There is one serious bug though, that I hope will one day be tackled > by some brave and patient soul. Tried. Failed. Not happening, sorry. > Its hard to demonstrate and almost impossible to catch in the act. That's basically the problem. That and that the editor core is thousands of lines of hard to read code. But if you can ever repro it... Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
Bob Spelten via Ql-Users wrote: > But setting a custom width, moving the "size" to the left, is where the > right side also moves left. OK, now I see what you mean. The size is incremented in 20 character steps. There is no explanation in the code why that is, but as this is the same amount that is used when the edit window is panned I guess that this is the reason. I tried removing the restriction and most things seemed to work, but I found at least a minor bug, so I'm not comfortable lifting that restriction. I can make the bottom right corner stay in place, though. The downside is that now when you resize less than 20 characters more basically nothing happens at all, this might be confusing for some users. > Jochen once explained that size grows in > discrete steps but I would expect the right side to be anchored, now full > screen can never be reached. Ususally it cannot be reached because the maximum line length is exhausted before the maximum screen width. > My numberless Basic is named xxx_bsl so would not benefit. > Usually I start QD through FI2 where the right command flag is added to > take care of this. I start 100 QDs when working on stuff like this, 10% by hotkey and 90% by FiFi ;) > Just one more. It sometimes happens when a line is longer than the window > and I use ALT-right to jump to the end of the line, the text pans less > than needed but the cursor/arrow lands on the right spot, outside the > window. > This seems more likely to happen when the cursor is already at position > 80+. Can't reproduce right now. And in any case, this is a problem with the editor core, which I'm not touching with a 10 feet pole. > Last one? Opening QD in read-only mode (\P) lets me pick a block for the > scrap but using ^Z to hot-buffer one line is not working. A bug or a > missed feature? Apparently you have to thank me that CTRL+X works in this mode: cmp.b #24,d1 ; CTRL X => Quit beq.s not_protected ; yes, so do it (Marcel wants it !!) I added cmp.b #26,d1 ; CTRL Z => Mark current line beq.s not_protected ; yes, so do it (Bob wants it !!) Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
On 28/08/2018 21:10, pjwitte via Ql-Users wrote: Op Tue, 28 Aug 2018 15:26:22 +0200 schreef Marcel Kilgus via Ql-Users : Bob Spelten via Ql-Users wrote: <> There is one serious bug though, that I hope will one day be tackled by some brave and patient soul. Its hard to demonstrate and almost impossible to catch in the act. In fact some people, including Jochen, deny its very existence: Its the "Creeping last line/rubbish bug". A scan through the SMSQ/E sources should convince doubters of its existence. In a number of files youll see a many lines gap from the last code line to the END directive. Heres one: <> I just want to correct an assertion made above: It is true (in my recollection) that Jochen was an unbeliever at first, but by 2001 he certainly knew about this bug (we referred to it as the cut'n paste bug), and he tried very hard to find and fix it. Per ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
Op Tue, 28 Aug 2018 15:26:22 +0200 schreef Marcel Kilgus via Ql-Users : Bob Spelten via Ql-Users wrote: Per already mentions the jumpy resize behaviour. I frankly don't quite see what's jumpy about it? My default QD size is 80 columns by 40 lines, and I like that a size DO makes it maximize the height. But setting a custom width, moving the "size" to the left, is where the right side also moves left. Jochen once explained that size grows in discrete steps but I would expect the right side to be anchored, now full screen can never be reached. It seems that the bigger the move to the left, the more the right moved along with it. Uh-oh. I think we have conflicting wishes here. If I understand you correctly, you are not able to re-size the the WIDTH of the window by HITting the window resize button and moving the icon to the left. Right? To achieve that you needed to DO the window resize button, which makes the window expand to maximum, something that no longer works in VB0.xx. The thing is, you CAN resize the window width using the standard Wman resize mechanism, but you need to move the resize icon some 150 pixels or more to the left for the next allowable width increment. I guess you need a screen width of at least 640 pixels, and to move the QD window as far right as possible to be able to resize the width to the next level. Thats why you wish for the old VA.xx behaviour. I agree this stepwise increment is a nuisance. Ideally the increment should be in the order of one or a few character widths; not 20. In VB.01 the behaviour changed somewhat. DOing the resize button would only maximise the HIGHT, leaving the width at whatever one had labouriously managed to set it (I usually prefer 100 columns for working). So that wouldnt help you, Bob. In VB0.3 the behaviour changed again. Now DOing the resize button annoyingly resets the width to 80 coloumns for some reason as well as maxing the hight. There are a number of bugs in QD. I shant list them here, as that might be seen like "looking a gift horse in the mouth", or worse: nagging ;) There is one serious bug though, that I hope will one day be tackled by some brave and patient soul. Its hard to demonstrate and almost impossible to catch in the act. In fact some people, including Jochen, deny its very existence: Its the "Creeping last line/rubbish bug". A scan through the SMSQ/E sources should convince doubters of its existence. In a number of files youll see a many lines gap from the last code line to the END directive. Heres one: dev8_iod_con2_qpc8_mblock_asm, from 2003 with a 37 line gap! That implies that you wont always see the problem, because its off-page. Whats worse is that you dont always know what the last line contains. Here are some with some rubbish at the end dev8_dv3_q68_sdhc_wsect_asm dev8_dv3_q68_win_card__asm both from 2018. Since the rubbish is past the END it wont matter here, but you can see the potential for strange, inexplicable bugs in other code - or perhaps even a nasty letter where you thought youd deleted what you really thought of someone.. The oldest Ive found in the SMSQ/E source files, so far is dev8_iod_con2_16_recol_asm from Dec 1998, ie just after QD VA.06 came out. Perhaps there is a connection? I did a general tidying up of the source files a year or two ago, so I caught a lot of the most extreme cases and fixed them, but I left a few for posterity - and new ones have emerged since. Anyway, that was just to try to convince any unbelievers. The issue has been with us for a very long time. I believe it has something to do with QD's block handling: copy, replace, delete..? But, as I said, its hard to get a clear idea of when it happens. Not least because most(?) of the time it happens out of sight below the bottom of the visible text. Per ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
Op Tue, 28 Aug 2018 15:26:22 +0200 schreef Marcel Kilgus via Ql-Users : Bob Spelten via Ql-Users wrote: Per already mentions the jumpy resize behaviour. I frankly don't quite see what's jumpy about it? My default QD size is 80 columns by 40 lines, and I like that a size DO makes it maximize the height. But setting a custom width, moving the "size" to the left, is where the right side also moves left. Jochen once explained that size grows in discrete steps but I would expect the right side to be anchored, now full screen can never be reached. It seems that the bigger the move to the left, the more the right moved along with it. One point I would like to add now, as a Basic programmer, is the DEFine highlight that is not working for FN or FuNction sections. Again a feature I didn't even know about. And quite obviously this has never worked but is not too difficult to fix. I'd prefer if the editor usage would switch automatically to BASIC if a file with the extension "_bas" was loaded (correspondingly for "_asm"), but I must check how difficult that would be. My numberless Basic is named xxx_bsl so would not benefit. Usually I start QD through FI2 where the right command flag is added to take care of this. For other points I need to check my notes and test them against this version. Can do, but as a general matter I must stress that me releasing some software does not mean that all outstanding 20 years old bugs will get fixed :-o One can only hope.;-) Just one more. It sometimes happens when a line is longer than the window and I use ALT-right to jump to the end of the line, the text pans less than needed but the cursor/arrow lands on the right spot, outside the window. This seems more likely to happen when the cursor is already at position 80+. Last one? Opening QD in read-only mode (\P) lets me pick a block for the scrap but using ^Z to hot-buffer one line is not working. A bug or a missed feature? Bob -- The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/; --- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
On 28/08/2018 14:45, Marcel Kilgus via Ql-Users wrote: pjwitte via Ql-Users wrote: Im having a problem with the latest QD (2018). The 'Replace confirmation sub menu' seems to have its colours mixed up. I cant read that menu in any palette! I've never used or seen this menu, but yes, it's broken. Jochen was being clever here, unfortunately without explaining comments in the menu/code what he did! Bad Jochen! The window actually has a "hole" in it that let the original text shine through. Apparently Bernd, who did the colour conversion, gave up understanding it. Took me halve an hour to get it, too. Unlike the last official release my sources are based on Bernd's version, so you got a confused and bugged halve-finished version of the window. The last official release just didn't colour the window at all. Well thanks for the effort :) If "someone" ;) is going to delve into the innards of QD again to sort this out, could they also tweak the 'resize to full screen' option (DO resize icon) to perhaps leave the current x-size of the window unchanged (as it was in the earlier version)? I don't think there ever was a version that left the x-size alone? As far as I can tell all previous versions just made the window a LOT wider, to the maximum allowed size. I much prefer the current behaviour. VB0.1 does. Per ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
Bob Spelten via Ql-Users wrote: > Per already mentions the jumpy resize behaviour. I frankly don't quite see what's jumpy about it? > One point I would like to add now, as a Basic programmer, is the DEFine > highlight that is not working for FN or FuNction sections. Again a feature I didn't even know about. And quite obviously this has never worked but is not too difficult to fix. I'd prefer if the editor usage would switch automatically to BASIC if a file with the extension "_bas" wa loaded (correspondingly for "_asm"), but I must check how difficult that would be. > For other points I need to check my notes and test them against this > version. Can do, but as a general matter I must stress that me releasing some software does not mean that all outstanding 20 years old bugs will get fixed :-o Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
pjwitte via Ql-Users wrote: > Im having a problem with the latest QD (2018). The 'Replace > confirmation sub menu' seems to have its colours mixed up. I cant read > that menu in any palette! I've never used or seen this menu, but yes, it's broken. Jochen was being clever here, unfortunately without explaining comments in the menu/code what he did! Bad Jochen! The window actually has a "hole" in it that let the original text shine through. Apparently Bernd, who did the colour conversion, gave up understanding it. Took me halve an hour to get it, too. Unlike the last official release my sources are based on Bernd's version, so you got a confused and bugged halve-finished version of the window. The last official release just didn't colour the window at all. > If "someone" ;) is going to delve into the innards of QD again to sort > this out, could they also tweak the 'resize to full screen' option (DO > resize icon) to perhaps leave the current x-size of the window > unchanged (as it was in the earlier version)? I don't think there ever was a version that left the x-size alone? As far as I can tell all previous versions just made the window a LOT wider, to the maximum allowed size. I much prefer the current behaviour. Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QD 2018 colours
Op Sat, 25 Aug 2018 18:45:31 +0200 schreef pjwitte via Ql-Users : Im having a problem with the latest QD (2018). The 'Replace confirmation sub menu' seems to have its colours mixed up. I cant read that menu in any palette! Since no one else has complained, and I recently made some changes, I was wondering if Im just being confused (again!) But then an older version of QD (2003) seems unaffected, although it too uses the old colourways settings for part of that menu. If "someone" ;) is going to delve into the innards of QD again to sort this out, could they also tweak the 'resize to full screen' option (DO resize icon) to perhaps leave the current x-size of the window unchanged (as it was in the earlier version)? Great that this program is now freely available! First of all, thanks Jochen & Marcel for setting it free. I have enjoyed using QD since '91 and it's the first program I added to QLE, Black Phoenix or my Q68 boot when exploring or customising them. Like Per I found something changed in this "Replace" confirmation window. Apart from the mixed m4/HC colours, the text to replace is no longer visible in any theme, m4 or HC, I tried. My HC QDvB always uses m4 colours here but at least I can see the text to be replaced. There are a few more small issues that should be addressed when "someone" updates the code. Per already mentions the jumpy resize behaviour. One point I would like to add now, as a Basic programmer, is the DEFine highlight that is not working for FN or FuNction sections. For other points I need to check my notes and test them against this version. Bob -- The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/; --- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com ___ QL-Users Mailing List
[Ql-Users] QD 2018 colours
Im having a problem with the latest QD (2018). The 'Replace confirmation sub menu' seems to have its colours mixed up. I cant read that menu in any palette! Since no one else has complained, and I recently made some changes, I was wondering if Im just being confused (again!) But then an older version of QD (2003) seems unaffected, although it too uses the old colourways settings for part of that menu. If "someone" ;) is going to delve into the innards of QD again to sort this out, could they also tweak the 'resize to full screen' option (DO resize icon) to perhaps leave the current x-size of the window unchanged (as it was in the earlier version)? Great that this program is now freely available! Per ___ QL-Users Mailing List
