New GUI for the Atari 8-bit

[+MrFish]

13 minutes ago, TheNameOfTheGame said:

...but if GOS was ever going to get near the usability of something like SymbOS (maybe an unfair comparison, but you get my meaning) then it would take some singular and intense focus on the development process, which the "on-going venture" just doesn't seem to allow without the GOS side generating some income stream to replace or supplement the firmware dev.

It really only needs to arrive at some reasonable beta stage, with a working file mananger/application launcher as a next step to becoming useful. Once there, and other interested developers are provided with some information on how to create applications for it, progress would be less dependent on FJC alone.

 

That being said, I'd like to see some crowdfunding behind the project.

 

[TheNameOfTheGame]

55 minutes ago, MrFish said:

It really only needs to arrive at some reasonable beta stage, with a working file mananger/application launcher as a next step to becoming useful. Once there, and other interested developers are provided with some information on how to create applications for it, progress would be less dependent on FJC alone.

 

That being said, I'd like to see some crowdfunding behind the project.

 

Yes, that would be a milestone and of course, as you say, then other interested devs could pitch in.  It could happen and I hope it does.

 

As far as crowdsourcing, I'm all for it.  There are several Patreon projects I support each month and I would gladly support a Patreon for GOS, but would there be enough interested people willing to commit funds on a monthly basis to actually make it work in this case?  Don't know, we are pretty small group and the ones that would donate would probably be even smaller.  Again, not trying to discourage the idea, just trying to gauge it realistically.  I wonder how much it would take monthly to make it a worthwhile proposition?

[+MrFish]

25 minutes ago, TheNameOfTheGame said:

As far as crowdsourcing, I'm all for it.  There are several Patreon projects I support each month and I would gladly support a Patreon for GOS, but would there be enough interested people willing to commit funds on a monthly basis to actually make it work in this case?  Don't know, we are pretty small group and the ones that would donate would probably be even smaller.  Again, not trying to discourage the idea, just trying to gauge it realistically.  I wonder how much it would take monthly to make it a worthwhile proposition?

There are plenty of interested people; but interested in funding is another thing. I'm sure it'd be a relatively small group. I suppose the more important part is whether it could provide enough keep FJC going. TBH, it's also one of the reasons why I had to refrain from working on the project myself. I still have a great interest in working on it -- and seeing the work that's already been done come to fruition; but I can hardly afford the time. This is why my websites have been languishing for months, recently, as well as many other Atari projects.

 

[+MrFish]

I guess one thing I can add here, in terms of progress, is that a lot of resources have already been created (or can be created relatively easy, pending format conversion). I think I've mentioned some of them before, but maybe a lot of people aren't aware. I've already created over 1,000 icons for the project, and in realm of fonts, I'd guess there are 30 to 50 quality fonts (most in a variety of point sizes) ready for conversion.

 

[ivop]

42 minutes ago, MrFish said:

I've already created over 1,000 icons for the project, and in realm of fonts, I'd guess there are 30 to 50 quality fonts (most in a variety of point sizes) ready for conversion.

Impressive!

 

Re proportional fonts, I never realized that the ST indeed uses monospace fonts and Apple used proportional fonts. That does indeed make a difference, even though it's still not enough to run two windows, one with documentation and one with an editor or word processor.  Just IMHO.

 

FJC's TUI library, as used in uflash, could really be a game changer for easy to use (stock) Atari programs. Like a MIDI player...

[flashjazzcat]

I looked into the GEOS font format a few months back while working on resources for another project, and I thought how wickedly ironic it would be to start using them in the Atari GOS. The file structure is interesting, but I didn't quite get to the point of writing a tool to pull the files off the disk images.

 

[+MrFish]

43 minutes ago, ivop said:

Impressive!

I've only created about 5 font types myself (at various point sizes totally about 30 font files) from scratch. The rest of the fonts are from collections culled from the old Macintosh computers. We actually have hundreds from there; but I say 30 - 50 because that's in the neighborhood of what we'd been looking at using to start with. There is, of course, no reason the others can't be made available for people/developers to use if they're interested. It's just more a matter of initial focus on some core resources that we'd deemed to be the most usable and interesting.

 

[+MrFish]

45 minutes ago, ivop said:

Re proportional fonts, I never realized that the ST indeed uses monospace fonts and Apple used proportional fonts. That does indeed make a difference, even though it's still not enough to run two windows, one with documentation and one with an editor or word processor.  Just IMHO.

You're right, it's not going to affect windows so much for applications (although that really depends on what kind of fonts are used and how they're used in the application); but what it does affect are file-manager windows, and the bulkiness and number of items on menus and submenus. You can't fit many filenames in a window with monospaced fonts; and the difference is pretty considerable. This was also the case with Diamond GUI, and one reason why the file manager didn't provide a good experience. Also, as a result, the large-sized filenames only made sense with larger icons (large filenames with small icons look rather comical). So, then even more space was eaten up. Diamond tried to compensate by not making its icons as tall as they were wide; but it didn't help much.

 

FJC and I spent quite a bit of time pondering out how many files could be represented in a single file manager window. Well, I probably spent more time on it; but I sent a lot of examples for him to look over, so we could make some decisions about various aspects; and then there was a fair amount of back and forth discussion about it. It's an important subject, when it comes to usability.

 

[+MrFish]

35 minutes ago, flashjazzcat said:

I looked into the GEOS font format a few months back while working on resources for another project, and I thought how wickedly ironic it would be to start using them in the Atari GOS. The file structure is interesting, but I didn't quite get to the point of writing a tool to pull the files off the disk images.

Yeah, I looked into their font format years ago too. The main thing about GEOS fonts is that they're limited in the number of characters/glyphs (IIRC) and they're typically available in only a few point sizes (something like 1 - 4 different sizes, depending on what type of font it is -- writing, or artistic type, etc.). GEOS stole a lot of their fonts from the Macs to begin with too; so, we have most of these fonts and in more point sizes already.

 

[flashjazzcat]

I just liked the idea of packaging multiple point sizes into a single file, and basically availing the GOS of the rather large collection of existing GEOS fonts. Plus which, some level of cross-platform resource compatibility (which I've been asked about quite frequently) would be nice.

 

[+MrFish]

1 minute ago, flashjazzcat said:

I just liked the idea of packaging multiple point sizes into a single file...

Ah, yeah... I'd forgotten about that. The Macintosh utilizes something called "Suitcases" to group font files together by family. The suitcase was actually a file, and then each point size was a resource within that. Later on, the suitcase was made to behave more like a folder, and each point size like an individual file -- which got rid of the need to have a special app for working with suitcases/font sizes.

  

1 minute ago, flashjazzcat said:

...and basically availing the GOS of the rather large collection of existing GEOS fonts.

They're decent, as I say, they were mostly stolen (maybe licensed -- I forget at this point) from the Mac to begin with; but I was less impressed with them the more I looked into them. I think they generally used only alphanumeric and standard punctuation characters, whereas the Mac counterparts of the same fonts had special characters, international, mathematical, ect. (usually 200 - 256 characters) ; and then lacking in point sizes, as I mentioned. Although I suppose the point sizes chosen were some sort of practical consideration, related to usability and file size.

 

1 minute ago, flashjazzcat said:

Plus which, some level of cross-platform resource compatibility (which I've been asked about quite frequently) would be nice.

Is GEOS still being used? You really received requests about this? I'm surprised...

As I mentioned to you before, I really tried my best to work with GEOS on multiple occasions via emulation, and I just found the thing totally unusable; really just a sluggish mess.

 

[FifthPlayer]

In terms of converting fonts from old platforms such as classic Mac and GEOS, how do you deal with new character glyphs that didn't exist at the time?  I'm thinking primarily of the Euro € symbol, but there may be others.  The big challenges (as I see them) would be to create new glyphs in the style for the typeface and then to find a character code for them.

Edited August 1, 2022 by FifthPlayer

[flashjazzcat]

Just now, MrFish said:

You really received requests about this? I'm surprised...

Certainly. I was a little surprised too. Some people asked for things like application compatibility with SymbOS too, and other such impossibilities.

[+MrFish]

1 hour ago, flashjazzcat said:

Some people asked for things like application compatibility with SymbOS too...

That wouldn't surprise me so much, given its depth and more-recent development. GEOS would be a bit perplexing.

 

1 hour ago, flashjazzcat said:

...and other such impossibilities.

Haha

 

I'm pretty sure our font format is more complex that either GEOS or SymbOS ( @Prodatron and I have already had a few words about it in this thread). I'm mainly speaking of the character advance parameter, which allows such things as cursive fonts and true italics that have portions intruding into previous character space (and accommodates monospace characters). But, I imagine compatibility would just mean having the parameter always equal to zero, as I think they both avoid such types of fonts (although I could be wrong about GEOS fonts -- as it's been so long since I've studied them).

 

[+MrFish]

1 hour ago, FifthPlayer said:

In terms of converting fonts from old platforms such as classic Mac and GEOS, how do you deal with new character glyphs that didn't exist at the time?  I'm thinking primarily of the Euro € symbol, but there may be others.  The big challenges (as I see them) would be to create new glyphs in the style for the typeface and then to find a character code for them.

Using a 256 glyph system, there are always unused places within Mac fonts -- from what I recall -- or places where they just stuck some non-standard graphic glyphs; and I think these are consistent enough to choose some spot across all fonts for any such characters that are needed. In the case of GEOS, it's definitely so, as they're not even using 100 glyph positions in almost all cases (maybe all).

 

I just had a glance at a few Mac standard, system fonts again, and they seem to be typically using either 217 or 240 glyph positions (the modern term is "code point"). So, there are plenty of position available to work with.

 

I'm pretty sure we had agreed on a few standards for ourselves already, and maybe left a few up in the air. I'd have to get my head back into the subject again...

 

Yes, some modern, missing characters will have to be created by hand. That's why I'm here.   It's not such a task, when you've done as much font work as I have; I have good tools too.

 

[Prodatron]

1 hour ago, MrFish said:

I'm mainly speaking of the character advance parameter, which allows such things as cursive fonts and true italics that have portions intruding into previous character space

 

Yes, this isn't possible in the textoutput in SymbOS yet. I am thinking about a new font format, which can handle very big fonts (up to 16K at least). Intruding previous character space is still not easy as you have to know which part of the previous char is empty and which part of the following char can be moved into it. At least I guess so?

[+MrFish]

24 minutes ago, Prodatron said:

Yes, this isn't possible in the textoutput in SymbOS yet. I am thinking about a new font format, which can handle very big fonts (up to 16K at least). Intruding previous character space is still not easy as you have to know which part of the previous char is empty and which part of the following char can be moved into it. At least I guess so?

I think our previous conversation on this answers your question.

 

It starts here, when I bring up font-spacing parameters.

 

I said it's mainly one parameter (which it is, generally speaking), above; but it's really the combination of two parameters (as I point out in the our old conversation), neither of which existed in our first font format.

 

[atarixle]

BOSS-X, my GUI written in Turbo-BASIC, uses proportional fonts since the beginning in 1993. And from 2000, it is the standard in almost all areas.

320x192 is enough space for a computer like the 1.77 MHz Atari, and the font face usually less than 8 by exactly 8 pixels fits perfectly.

Use a font like Chicago (Mac, re-created for BOSS-X), which looks the same with or without sub-pixel rendering, and you have an UX that looks clean and kinda modern.

Edited August 2, 2022 by atarixle

[Prodatron]

11 hours ago, MrFish said:

I think our previous conversation on this answers your question.

 

It starts here, when I bring up font-spacing parameters.

Thanks MrFish, sorry I forgot about this (again 7 years passed ? )

[+MrFish]

5 hours ago, Prodatron said:

Thanks MrFish, sorry I forgot about this (again 7 years passed ? )

I don't think we wrote up a spec for the last font revision (should be "E"), otherwise I'd just let you have a look at that. All we have is the revision "D" doc -- unless FJC wrote something up at some point.

 

[Edit]

OK, it looks like I'm wrong about that. I have here a Rev. E (Draft) that FJC wrote, and then I have my edit of the draft with with notes/questions for FJC to look at. So, I'm not sure if he did any more edits; and I don't recall if we had any more dialogue over documentation. I know he wrote his Java font converter app some time after that (years later?).

 

So, I can let you have a look at the doc that I have, or you can look at what he has, if it's a later update.

 

The doc I have has a modification date of 4/26/2012. So, we'll see what FJC has...

 

[flashjazzcat]

On 8/2/2022 at 2:57 PM, MrFish said:

So, we'll see what FJC has...

Rev. E, more or less the same date.

[+MrFish]

1 hour ago, flashjazzcat said:

Rev. E, more or less the same date.

Alright... I figured as such. Apparently good enough for you to create your Java font converter. I think you did a demo of Rev. E in action with the GUI too.

 

I only see one major omission from the doc, which is the x-offset table definition.

 

After 10 years, I can see at least one thing that would be a helpful addition, though: a simple visual diagram.

 

[bradc]

FJC, just kicking this topic to see how things are getting along?  Thank you, always, for all of the hard work.  Can't wait for something we can help with and write apps for.

[flashjazzcat]

4 hours ago, bradc said:

FJC, just kicking this topic to see how things are getting along?  Thank you, always, for all of the hard work.  Can't wait for something we can help with and write apps for.

Remarkably, I haven't done a thing with the GOS for almost ten years now, having been wholly absorbed in U1MB/Incognito/SIDE firmware maintenance since 2015. I think the project also became hard to manage owing to lack of assembler support for certain features (something that still isn't resolved) and attempts to build in support for VBXE (via display drivers, requested at the time). Hopefully now we own our own home, and once the initial period of bottomless-pit expenditure has passed, I'll find time to work on projects not directly linked to the generation of revenue.

[danwinslow]

My two cents - leave the vbxe and other fancy hardware out of it for now. Finish the original core base, leaving things set up so that folks  can reasonably easily add features - i.e., APIs are present for the core system and for a device driver layer.