Does anyone know if it is possible to customize SpeedUI's fonts? I like the 6 level stack, but I prefer using my own fonts. Are the fonts designed to be 6x4 (6 rows of pixels, 4 columns wide)?
the SpeedUI 6x6 stack level display font is built-in into the engine, internally double compressed, and thus not customizable at the moment.
The other fonts used in the input forms, choose and message boxes are either the HP-48 built-in fonts, or taken from UFL if the UFL is installed.
There are plans for one of the next SpeedUI releases to "outsource" the SpeedUI 6x6 stack font into an enhanced version of the UFL, maybe as font 3 or 4.
That would allow to customize the look, and also streamline some of the inner workings of SpeedUI;-)
> Does anyone know if it is possible to customize SpeedUI's fonts? I > like the 6 level stack, but I prefer using my own fonts. Are the fonts > designed to be 6x4 (6 rows of pixels, 4 columns wide)?
I noticed that the commands such as xINEG, xI-, etc. were compiled to have EQWR properties, among others. However, they do not seem to behave as expected when used in the EQWR. Or is there something I'm not understanding about these attributes?
On Oct 21, 11:50 am, "Raymond Del Tondo" <Ih8...@nowhere.com> wrote:
> the SpeedUI 6x6 stack level display font is built-in into the engine, > internally double compressed, > and thus not customizable at the moment.
> The other fonts used in the input forms, choose and > message boxes are either the HP-48 built-in fonts, > or taken from UFL if the UFL is installed.
> There are plans for one of the next SpeedUI releases > to "outsource" the SpeedUI 6x6 stack font into an > enhanced version of the UFL, maybe as font 3 or 4.
> That would allow to customize the look, > and also streamline some of the > inner workings of SpeedUI;-)
> > Does anyone know if it is possible to customize SpeedUI's fonts? I > > like the 6 level stack, but I prefer using my own fonts. Are the fonts > > designed to be 6x4 (6 rows of pixels, 4 columns wide)?
> I noticed that the commands such as xINEG, xI-, etc. were compiled to > have EQWR properties, among others. However, they do not seem to > behave as expected when used in the EQWR. Or is there something I'm > not understanding about these attributes?
Possible bug? Have alpha-mode lock on, but not lower-case lock. Now, press (and hold) left-shift to type lower-case letters. Only the first letter gets lower-case'd, and the remaining letters are still capitalised even while left-shift is held down.
[alpha] [alpha] [leftshift (hold for next three keys)] [A] [B] [C]
> Possible bug? Have alpha-mode lock on, but not lower-case lock. Now, > press (and hold) left-shift to type lower-case letters. Only the first > letter gets lower-case'd, and the remaining letters are still > capitalised even while left-shift is held down.
> [alpha] [alpha] [leftshift (hold for next three keys)] [A] [B] [C]
Here's another bug (mostly cosmetic, but can be confusing). I was editing the following program (entered here exactly as is viewed on the HP48, including linebreaks).
<< TIME '1-COS(X^2+Y^2 ^2)/(X^2+Y^2)' -3.5 3.4 -3.5 3.4 15 15 PLOT3D TIME ROT HMS-
Place the cursor on the 'C' in the function COS and press the DEL-> key. The screen shows:
<< TIME '1-COS(X^2+Y^2 << TIME '1-^2)/(X^2+Y^... 3.4 -3.5 3.4 15 15 PLOT3D TIME ROT HMS-
Basically, keep pressing <-DEL or DEL-> on the menu and you will see that the screen does not properly update. I'm guessing there was a MOVEUP routine that did not have a followup routine to blank out artifact pixels.
Out of curiosity, is the fast editing routine a part of UI.LIB? Or is it part of CF.LIB? UI.LIB seems based off of Java, but yet is smaller.
thanks again for the bug report. Actually the edit display row update bug is in the todo list for a while, however it's only a cosmetic thing, but will be fixed, of course:-)
> Out of curiosity, is the fast editing routine a part of UI.LIB? > Or is it part of CF.LIB?
Both. The display engine and decompiler resides in CF.LIB, various new ML edit functions reside in UI.LIB
> UI.LIB seems based off of Java, but yet is smaller.
The fast stack display was not based on JAVA, but on my own six level stack display routine, which used a modification of the self-contained standard frame POL for a 5-level stack display routine from about 1991, which we used in the RPL48 package.
When I included the ML decompile routine from Will Laughlin, I had to adjust various routines of my stack display to match the output of the ML decompiler, hence there are some similarities now.
The fast SpeedUI editor has nothing to do with the edit mode in JAVA, the only commonly used routine is the ML decompiler from Will, with some modifications from me. Everything else was written new from scratch, and that's why scrolling is that fast:-)
CF.LIB can be seen as base library, a concentration of all functionalities which are used in more than one SpeedUI component. That's why CF.LIB is that big in size now;-)
In one of the next releases, there may be an option for a stripped down CF.LIB , which doesn't include the ML decompiler. That'll save another 11 or 12K, but will of course have some impact on the overall performance.
> Here's another bug (mostly cosmetic, but can be confusing). I was > editing the following program (entered here exactly as is viewed on > the HP48, including linebreaks).
> << TIME '1-COS(X^2+Y^2 > ^2)/(X^2+Y^2)' -3.5 > 3.4 -3.5 3.4 15 15 > PLOT3D TIME ROT > HMS-
> Place the cursor on the 'C' in the function COS and press the DEL-> > key. The screen shows:
> << TIME '1-COS(X^2+Y^2 > << TIME '1-^2)/(X^2+Y^... > 3.4 -3.5 3.4 15 15 > PLOT3D TIME ROT > HMS-
> Basically, keep pressing <-DEL or DEL-> on the menu and you will see > that the screen does not properly update. I'm guessing there was a > MOVEUP routine that did not have a followup routine to blank out > artifact pixels.
> Out of curiosity, is the fast editing routine a part of UI.LIB? Or is > it part of CF.LIB? UI.LIB seems based off of Java, but yet is smaller.
> > Out of curiosity, is the fast editing routine a part of UI.LIB? > > Or is it part of CF.LIB?
> Both. The display engine and decompiler resides in CF.LIB, > various new ML edit functions reside in UI.LIB
I see. The ML edit is fantastic! SpeedUI continues to give the HP48 another breath of fresh air.
> > UI.LIB seems based off of Java, but yet is smaller.
> The fast stack display was not based on JAVA, > but on my own six level stack display routine, > which used a modification of the self-contained > standard frame POL for a 5-level stack display routine > from about 1991, which we used in the RPL48 package.
> When I included the ML decompile routine from Will Laughlin, > I had to adjust various routines of my stack display > to match the output of the ML decompiler, > hence there are some similarities now.
Ahh, I see now. I actually still have RPL48 installed on an old HP48SX. Was the POL you mentioned at all related to the SOL back when folks were working on speeding up the HP48SX? Both were fantastic packages. BTW, I REALLY love how nice the editor is with this latest release of SpeedUI!
When set to use small fonts for algebraic objects, the display of the stack level of certain algebraics is inconsistent.
1. Compare 'X^2' vs 'X-1' with small fonts enabled. Clear the screen, then switch to medium fonts, and re-enter the same two equations.
2. Leave 'X^2' and 'X-1' on the stack, and switch between small and medium fonts. The cache does not update, but the stack level indicator changes sizes as seen in 1.
Also, when the clock is turned on, the stack is nonempty, and there is currently an error message up in the status area, pressing [up] to enter the interactive stack leaves a bit of garbage left where the clock should appear.
Example:
Stack has one object 1: 2 press [y^x] [up]
On Oct 27, 2:51 pm, rs1n <handuongs...@gmail.com> wrote:
> When set to use small fonts for algebraic objects, the display of the > stack level of certain algebraics is inconsistent.
> 1. Compare 'X^2' vs 'X-1' with small fonts enabled. Clear the screen, > then switch to medium fonts, and re-enter the same two equations.
> 2. Leave 'X^2' and 'X-1' on the stack, and switch between small and > medium fonts. The cache does not update, but the stack level indicator > changes sizes as seen in 1.
About the bugs: 3 of the 4 have been fixed for SpeedUI v9.08 , I hope to get the last one fixed soon.
About the Alg mode: That was one of the things which were not part of my original stack interface design, and I had no intention to include it.
However, at some point there were users who wanted this feature, so I included it.
The cache update bug only occurs after changing the alg font size. After changing the setting in the config dialog, Java had an explicit WipeCache call for this. Since my config dialogs are independent from the SpeedUI stack interface, this wasn't the way to go. Instead, I introduced kinda stack flag cache, whose settings are checked at certain places. This mechanism detects alg font size changes, and clears the cache if necessary.
The edit mode line shift bug was caused by a missing ML RTN line...
The review mode trash status line area was caused by a missing display update instruction.
These have been fixed so far.
One of the next releases will have the path display with UFL font support.
>> > Out of curiosity, is the fast editing routine a part of UI.LIB? >> > Or is it part of CF.LIB?
>> Both. The display engine and decompiler resides in CF.LIB, >> various new ML edit functions reside in UI.LIB
> I see. The ML edit is fantastic! SpeedUI continues to give the HP48 > another breath of fresh air.
>> > UI.LIB seems based off of Java, but yet is smaller.
>> The fast stack display was not based on JAVA, >> but on my own six level stack display routine, >> which used a modification of the self-contained >> standard frame POL for a 5-level stack display routine >> from about 1991, which we used in the RPL48 package.
>> When I included the ML decompile routine from Will Laughlin, >> I had to adjust various routines of my stack display >> to match the output of the ML decompiler, >> hence there are some similarities now.
> Ahh, I see now. I actually still have RPL48 installed on an old > HP48SX. Was the POL you mentioned at all related to the SOL back when > folks were working on speeding up the HP48SX? Both were fantastic > packages. BTW, I REALLY love how nice the editor is with this latest > release of SpeedUI!
SpeedUI 9.08 is a bugfix release only. It fixes the four display update bugs, and introduces one small optical change: The empty space chars beneath the brackets in the PATH status display have been omitted to make room for up to two more chars.
The next major release "10" may have switchable fonts for the stack display.
These will also be editable, since they are located in an extended version of the UFL, which will include my 6x7 stk font as FNT3, and maybe (or optional) a 5x9 font for mimicing the 4-level stack display within SpeedUI.
This is the plan, and I'm currently preparing some things for it, but there's still some work to be done;-)
On 9 Nov, 23:34, "Raymond Del Tondo" <Ih8...@nowhere.com> wrote:
> SpeedUI 9.08 is a bugfix release only. > It fixes the four display update bugs, > and introduces one small optical change: > The empty space chars beneath the brackets > in the PATH status display have been omitted > to make room for up to two more chars.
> The next major release "10" may have > switchable fonts for the stack display.
> These will also be editable, > since they are located in an extended version of the UFL, > which will include my 6x7 stk font as FNT3, > and maybe (or optional) a 5x9 font for mimicing > the 4-level stack display within SpeedUI.
Sounds good. The big fonts do make for easier reading.
Regarding the bug where certain algebraics were displayed with a stack level indicator that is of the wrong size -- is this a bug in the AGROB routine? This bug appears to be still in EQSTK and Java as well. I use EQSTK for my HP48SX (smaller size) and it annoys me that EQSTK does not have a consistent font size for the stack level indicator.
On Nov 6, 6:33 pm, "Raymond Del Tondo" <Ih8...@nowhere.com> wrote:
|
