Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Alfredo Fernández Díaz

Pages: [1] 2
Applications / Re: XWP v1.0.12 Beta 1
« on: December 20, 2017, 11:52:25 pm »
Please do, your stuff looks pretty good! : )

General Discussion / Re: OS/2 application developers
« on: December 18, 2017, 02:54:14 pm »
What Lars said, 'only' everywhere.

In the year 2017, this being a mostly theoretical question anyway, applications should expect APIs with no duplicate functions except maybe for legacy application support, and that will hit no practical limits in the foreseeable future in a stupid way: if sizes of anything being handled (memory size? file name length? what have you) would overflow this and that, then do it some intelligent way: assume it can be presented as a series of chunks, or however, to applications that are not too stupid (or old). At a minimum, any such things we have seen in the past, we shouldn't see in the future.

Arithmetic precision in REXX is arbitrary at the expense of lengthier/slower operation. I know there is a difference between interpreted languages and implementing a (presumably) low-level API, yadda yadda,  but the basic principle I allude to is the same one again: handle things (especially things that are likely to change in predictable ways, like continually skyrocketing sizes of everything) intelligently.

Over and out :)

Applications / Re: XWP v1.0.12 Beta 1
« on: December 17, 2017, 01:45:54 pm »
David, long time no-read : )

Those look good here, as always with your icons. Now, this may not be important --in the end you (I) end up seeing icon X or icon X with 'some overlay' so you know it's a shadow regardless of the actual overlaid image anyway--, but I don't find the check mark or Shadow character images really convey the whole 'proxy icon' idea. Maybe it's worth to explore something more along the lines of arrows or chain links to see what you come up with?

Just a thought, as I said all work for me in the end :)

Setup & Installation / Re: How to - Install Fonts on OS/2
« on: December 17, 2017, 11:37:03 am »
I was actually kinda surprised a couple of times that 'modern' font software still generated an 'OS/2' table, or leave it intact. I assumed Windows would have started to use its own one shortly after the big split, and that it would be called something different -- but I rarely browse binary files to find out what is inside as long as software works. You live and learn ;)

General Discussion / Re: OS/2 application developers
« on: December 16, 2017, 03:43:15 pm »
Not a "serious" application developer in OS/2 land, I've coded some here and there.

The OS/2 API seems more than capable for everything I have wanted to do, I missed nothing -- I don't do 3D multimedia animation, or anything that flourished after the API was fleshed out, where I suspects most real lacks (if any) must lie. Sometimes the API forces doing things in a way that seems strange to me, but that may be because I'm not familiar enough with it. However, as the large file API has been mentioned, I'll say I'd like to see a 'clean' approach in some areas, *if* it's possible, and I'll use that as an example:

When file sizes were limited to 2GB, file position pointers, etc. could be expressed by a four-byte natural number (2^32 = 4GB), and that's the size of most file handling API arguments at the time. Support for anything beyond that "naturally" required new functions with would allow wider arguments, hence we have a parallel file API for large files.

From my point of view as a non-specialist in low-level implementation of such APIs, I'd like to have one working set of file APIs that would do its thing according to argument size (> vs <= 32 bits for starters), and any necessary redirecting APIs to address legacy applications. All APIs should be 'open' regarding that (argument size, or even number) if I am getting the point across (am I?). The FTP protocol comes to mind to further illustrate the point: at some point we needed newer clients and servers that could do 'huge' files; no protocol changes were necessary because that was handled in a more future-proof way (IIRC file size is transmitted as a decimal string, so any limitations of that are WAY into the future).

General Discussion / Re: ES/1 open source kernel
« on: December 16, 2017, 03:13:34 pm »
Sorry, we can discuss my own ideas of how we could have a better Unicode some other day, it would require much thinking and long-term plans of interoperability -- assuming it would actually be better ;)

What I meant to say is that any new thing of yours that wants to talk to other software today must readily implement Unicode as we have it today (or interfaces to it), and not get stuck in the codepages stage. If it is not, fine :)

General Discussion / Re: ES/1 open source kernel
« on: December 16, 2017, 02:55:42 pm »
ASCII goes 0..255 in my opinion. :-)
But that's what the codepage mess was about from the start. All codepages I know of* (classic ones, I don't know if the term has caught on a new meaning lately) are 255-character sets, and every character on any of them is therefore represented by one byte. And that's the problem: simplifying quite a bit, you only 'know' character 0x65 is an 'A' because ALL codepages have 'character 0x65 = A' in their definition. But the answer to 'what is character #128' (or whatever > 2^7 -1 = 127)? depends on what codepage you are using. You can't just put say Spanish and Russian ASCII text together like that because the same numbers above 127 represent different characters, etc. Unicode was conceived to get rid of those problems, but had to be retro-fitted unto existing systems, which caused problems of its own.

If you asked me, my own Unicode implementation would be very different from what we have currently, but that's another story. If you are beginning something from scratch, and want it to be able to eventually 'talk' to the rest of existing software, proper Unicode support is a must because it is nearly universal now.

*I am leaving DBCS CPs aside for the sake of simplicity. These are of course 65535-char codepages, hence 'DBCS'.

General Discussion / Re: ES/1 open source kernel
« on: December 16, 2017, 01:58:16 pm »
For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I will unveil the font tool next.  You will see limited ES/1 updates until then.
You may want to check Alex Taylor's bitmap and vector fonts -- I think his license would let you relieve quite some work from that front. Custom tools or not, I don't think you have developed a third way to define glyphs* so you probably can re-use work.

*You haven't, have you? :)

For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
Just like it is a subset of all codepages, ASCII is also a subset of unicode (ASCII chars are unicode chars 0-127), so why do you need funcA?

General Discussion / Re: ES/1 open source kernel
« on: December 16, 2017, 01:23:58 pm »
Just a quick question: unicode?

Setup & Installation / Re: How to - Install Fonts on OS/2
« on: December 05, 2017, 08:08:28 pm »
Unfortunately the font palette also requires you to have the ability to drag and drop. But after going through ArcaOS documentation in the OS/2 help file, they changed the drag to the right button instead of the left...
As Dave said, OS/2 default for dragging was always MB2 (usually the one on the right).

Strangely enough dragging an icon into the font palette in ArcaOS does nothing, but fortunately dragging it into the original font view does install it.
You drag "fonts" (an abstract construct for "font settings") from the palette and drop them onto any UI bit you want to use them to display text; you drag font _files_ (not icons) to the "fonts" folder in System Configuration to have them installed and used by the system (i.e. before you can see them in the palette). The similarity in names may be confusing.

I opened up the font and it does nothing to OS/2, so it's exclusive to Microsoft's "OS/2 font table" that's still a part of Windows.
The problem reported seems to be in Windows (win32k.sys) handling of TTF files with a malformed/corrupted OS/2 table (an internal structure of the font file intended for use under OS/2). I would think Windos should ignore that, but hey... OTOH a TTF file with a corrupt OS/2 table is likely to not work, or stir trouble, depending on how well your OS/2 TTF driver (IIRC truetype.dll or freetype.dll) handles the corrupt data.

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 05, 2017, 07:40:19 pm »
André, as I said, I'll be doing a cleanup of my own stuff soon, and now I'm sure we'll able to do the same at Netlabs. We should have less packages in the future than we have now, namely one current release, and *maybe* legacy FTEs --if they can't be removed from Hobbes--, but it will still take some time to unify, etc. I see the manual has been downloaded a number of times now, so please, don't post those anywhere else (Hobbes) unless I do get hit by a truck before we can proceed with the official release.

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 05, 2017, 06:40:33 pm »
Hello, Martín, I see you've been editing the project wiki. Why not, I'm not clear on where you want to use that besides the wiki page? but I'm open to the concept.

However, I personally favor losing the slash in the name altogether. It is implied in the new VIO icon I created (see attachment  #1), but that's not set in stone. If it depended on me alone, though, that would be as much as you would see of it again. It think it was historically a bad idea to have that in "OS/2", so why repeat the move.

Re: your svg, if it looks like the PNG it will fit more the PM version, I think, but I can't view it in SeaMonkey (shows a blank page). I always code SVGs by hand in eFTE2 so I don't know what's up with your code (see attachment #2, table-of-contents icon for the HTML manual, for a simple example that works here).

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 04, 2017, 07:45:16 pm »
Hi, Martin, thank you. Now that I have access again, I will soon upload the manual to the main repository, either after some refactoring, or in its current form if I get no feedback within a reasonable amount of time. From my experience I thought I would have to wait a bit more to do it so I tried to make the interim productive.
Lars, sorry if I got a bit overboard, I tried not to. Regarding NEPMD and Andreas, I think now you can ask him to publish both a new version *and* a valid, updated, visible contact address with it ;)

However, please note his words: "I noticed they've closed my old web site". Sounds familiar? It's not just Netlabs.

So far my activity has come mostly in bursts, but that's the way it is for most of us. The problem is, the fewer we are, the more that builds up with everybody else's discontinuities. I don't doubt Adrian may still be very helpful (last time we met was like 15 years ago), but what Netlabs really needs and lacks is some working self-sustaining infrastructure. Of course some admin has to know who you are before granting some privileges, of course site revamps are necessary from time to time, but it's entirely beyond any common sense that you need to get in touch with them every single time anything happens when you look away--It's not that I was cut off even from projects I managed (notably FAT32): in 2017 I can't even reset my own passwords TTBOMK. What if a project's admin goes away for a while? Or something really bad happens? Yet another discontinuity. Or a bunch of them. Or the final one: "Oh, I lost access to X/Y/Z. Again. F*ck it."

Over time I have came to limit the time fraction I will devote to chasing people around, so I can actually try and write stuff instead. Now that I can commit and publish properly again, tidying and cleaning up will come soon, rest assured, but given the current state of affairs I'm afraid that shrink-wrapping stuff will remain a second priority for quite a while.

Thanks for reading. Back to the manual? :)

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 04, 2017, 01:32:12 pm »
I don't think lack of coordination is exclusive to the world of OS/2. I belong to several other 'circles', so to speak, and I see the same patterns/problems with people losing interest and retreating into their caves, then coming out into the daylight again, only to find the world has changed but never left a note for them... It just hits us harder because there are fewer of us and word of mouth doesn't spread anymore--you need to keep asking people about everything, which IS kind of backwards if you ask me.

Sure, a great many projects have suffered (and still suffer) from lack of coordination, but at least some of us are working to get something together again. Are you really interested in the details, or was it all rhetorical? Am I the only one who got forgotten and cut off when changes were made to Netlabs after years of inactivity? I kind of doubt that. Maybe I am the only one stupid enough to keep trying to come back.

Now I know I can commit stuff again, and so I will when I have more updates -- but until everything got finally cleared out I thought it might be better to publish what I had where I could, rather than keep it to myself and wait to get access again, or get hit by a truck meanwhile. Please excuse me if that bothered you.

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: November 30, 2017, 01:26:57 pm »
If we should have learned something from IBM's Paradox of the active user besides that people don't want to read manuals, is that manuals are not there to make people use products, but rather to enable people's use of products to be, well, as productive as possible within given product designs. New users may be attracted to a product because a manual tells them how it works better for them than similar products, however.

I use NEPMD myself, and I used IBM-supplied EPM. It's not the 80s any more, so I expect any user to be able to use (e)FTE(2), (N)EPM(D), or any other text editor with pull down menus without reading a manual for that. File -> open, Edit -> Copy, etc., should be obvious to everyone by now, like using a mouse has become for the most part. Scratching the surface and trying out extra, non-obvious menu entries to see what happens is entirely up to users. But these programs go way beyond the basics common to all editors, and how to take advantage of that is often not self-evident. That's when the manual can make a difference. You may have a great one that even being incomplete gets you on track with what you can do and how (NEPMD), or a bad one that won't (EPM). Or, as was the case for FTE, you can be left out in the cold with a dry, cryptic reference to some 'internal commands' (?), and your curiosity. That is the gap I tried to plug with my first version of a manual for it, not more, not less. The question remains whether I did a reasonably good job, and whether it's worth to invest more time on future versions.

Regarding your other comments:

All the zipped FTEs  you can find at Hobbes work out of the box (I tried them all) -- unzip and run, no assembly required. Therefore, I would hardly have a problem with users developing their own extra/enhanced configs and sharing them (just like M. DeBusk or myself did) for others to try. I would hardly have a problem either with developers picking that up and bundling it with a newer version, just like M. Greene did: you never had to "download and install yet another" nothing. If you downloaded any of *my* config packages to try and get them running on your system, anyway, they all came with their little readmes trying to explain the why and how of it all, and revision histories.

If you're worried there are several versions of anything, what can I say. I always tried to keep just the latest one of *my own* stuff and I will clean up again soon -- it's not my fault if archivists at Hobbes went missing for a month, then went back to work just at the right time.

As for the .WPI, it includes (a version of) my configs, but I didn't produce the archive, let alone upload it to Hobbes. If you are curious about why I published new configs in parallel to the WPI, it just so happens that the current developer forgot to tell me he was modifying my work, or was going to release it, or ask me if I had gone on with it for the last six years, which turns out I had. And alas, while my own configs still work flawlessly with the older FTEs, they need to undergo modifications to work with what is inside that WPI I knew nothing about. We are trying to work out the current situation, so I am confident there will be fewer 'packages' to confuse you in the future. Meanwhile, I decided I could still contribute in other positive ways, like trying to document a great program for the benefit of others.

Pages: [1] 2