How to make iconx script file minimize

[kolla]

OK, since I only get answers that for me are irrelevant and not really what I am asking about, I assume then that there is no difference between using IconX and setting S bit and tooltype CLI

I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.

[Brian]

OK, since I only get answers that for me are irrelevant and not really what I am asking about, I assume then that there is no difference between using IconX and setting S bit and tooltype CLI

I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.

I don't know how you would set shell size and title without IconX... with CLI you just get a shell that ignores S:shell-startup as far as I can see (or have I missed something).

With IconX you don't have to confirm the action after the double click  on the icon.

[guest11527]

Sure - but it is a rather intrusive and... in lack of better word, "bloated" option when all you want is iconify and tab completion.

If this is all you want, why do you then look into the preferences at all? I'm sorry, I do not get this argument. If you don't need an option, don't touch it. It's just sitting there to be used in case, that's all.

Yes, and I suspect most people do not know it is there and certainly not how to set it up and use it, as I said, the configuration of ViNCEd is quite daunting.

You use the installer. Isn't that obvious? It will install the default configuration which is what most people will likely be happy about.

KingCON also does not have tabs, but the handler is half the size of vnc.library, and can even be put in kickstart and work when booting without startup-sequence (Yes, I know... copied to RAM before execution, still useful though.)

Putting "something in Kickstart" is not a recommended option for third party components anyhow. Actually, nothing but the absolute minimum on components should go there. Did you say "bloat?" There you go.

Well, the world has moved on, vt220 is not exactly the benchmark for a good terminal anymore.

And the benchmark is? If you look into the Linux world, the terminals there all support not much more than vt220, in certain variants. xterm has a couple of extras (ViNCEd supports them), and mrxvt, too. Then we have gterm, ... you name it. There is not much more.

ViNCEd has ANSI terminal with colours, which is nice, but 16 colours ANSI terminal is also kinda "old school" in these days of true colour xterm and consoles.

Actually, if you look at xterm, it supports... 16 colors. Obviously, because that is all ANSI CSI sequences can do. I do not know about xterm, but ViNCEd allows you to change these colors, not only at the preferences, but also by CSI sequences. Search for "CSI V" in the fine manual. This is, of course, a non-standard extension because VT220 has nothing to say about true color terminals.

There is option for tmux to deal with 256-colour terminal, but not for only 16 colours, for example.

Hardly an ANSI terminal then.

In my experience, both Term and AmTelnet (that is, the terminal MUI class) are better choices for simple terminal emulation, and it always helps to use GNU screen in the other end, less need for ctrl+L frenzy. And, then there is the question of charset handling.

The Amiga charset has ever been ISO-Latin-1. Changing that is a daunting task simply because the whole rendering engine, graphics upwards, only supports 256 glyphs in a character set.

That may be why. emacs lives in its own "retro reality" and (like vt220), should not be the benchmark for whether a terminal emulation works or not. But we are touching the main topic here - why should the console handler on the Amiga even have terminal emulation at all?

Because otherwise tools like the screen editor "ed" would not work? The choice to include a terminal was made at Tripos terms, where the user frontend of choice was (still) the terminal. Once this was set, it became necessary to include a "terminal emulation" in the system, which is what CON: does, actually in the given implementation as a thin interface around console (which is non-tripos, but tripos had something similar).

Anyways, I do think ViNCEd is awesome, but I also see why people rather use KingCON (Kingkong is something else). It would be nice with a new console handler that implements the basics like KingCON does, but in a more system friendly way. If someone with the know-how could make a video tutorial for all the stuff one can accomplish with ViNCEd, I would love watching and learning

The problem here is that you confuse a bit the role of the console.device (which is one thing) with that of the console handler (CON:) which is another thing. Kingkong just hacks up the console.device, probably causing problems should it ever be upgraded. CON: is a thin layer around console. So was Newcon. ViNCEd is a self-contained handler, it does not (really) use the console.device at all.

What *should* really be done is to first replace the console.device (which is a daunting task, because it is all assembly, same problem as ViNCEd), then create a Boopsi wrapper around this, to have a clean intuition layer for a console (also helpful in a lot of other situations), and then create a dos.library wrapper around that again (CON:), and finally integrate functionality in the shell that belongs there (Tab expansion is a shell feature, not a console feature).

However, that is a major task, requires a major restructuring of the Os, and completely out of reach with the available workforce.

How to use ViNCEd? Do you really need a video tutorial how to run the installer? That's really all, nothing more needed. Don't make things more complicated than they are.

[kolla]

I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.

Indeed, after playing around with it some more, IconX allows tooltypes that are otherwise ignored, I see WINDOW, STACK, USERSHELL, WAIT and DELAY. When launched using just S-bit, the tooltypes CLI and DONOTWAIT are used, and I suspect STACK too.

[kolla]

If this is all you want, why do you then look into the preferences at all? I'm sorry, I do not get this argument. If you don't need an option, don't touch it. It's just sitting there to be used in case, that's all.

It's like getting a 7 course meal when all you wanted was a cup of coffee.

You use the installer. Isn't that obvious? It will install the default configuration which is what most people will likely be happy about.

If "most people" were happy with this, "most people" would not be using KingCON. However, most people are using KingCON, so I presume "most people" are not so happy with VNC. Why is that? Well, I have mentioned quite a few reasons.

Putting "something in Kickstart" is not a recommended option for third party components anyhow. Actually, nothing but the absolute minimum on components should go there. Did you say "bloat?" There you go.[/QUTE]

This is about functionality - by putting KingCON in kickstart, tab completion and various other features are there also when booting without startup-sequence, or when booting to other filesystems (floppies, games etc).

Is there any way to have ViNCEd available like this? I think not.

And the benchmark is? If you look into the Linux world, the terminals there all support not much more than vt220, in certain variants. xterm has a couple of extras (ViNCEd supports them), and mrxvt, too. Then we have gterm, ... you name it. There is not much more.

mrxvt is ancient software now and gterm is also not really a good terminal

Anyways, there is much more. xterm also does vt420 and has its own extensions, such as the color255. If you look at modern implementations such as iTerm on and others for Linux and BSD etc, that can also output graphics directly to the terminal window.

Actually, if you look at xterm, it supports... 16 colors. Obviously, because that is all ANSI CSI sequences can do. I do not know about xterm, but ViNCEd allows you to change these colors, not only at the preferences, but also by CSI sequences. Search for "CSI V" in the fine manual. This is, of course, a non-standard extension because VT220 has nothing to say about true color terminals.

http://www.mudpedia.org/mediawiki/index.php/Xterm_256_colors

Hardly an ANSI terminal then.

As I keep saying - the world moves on!

The Amiga charset has ever been ISO-Latin-1. Changing that is a daunting task simply because the whole rendering engine, graphics upwards, only supports 256 glyphs in a character set.

It has already been done. MorphOS's terminal MUI class does this.

Because otherwise tools like the screen editor "ed" would not work?

Let me just shortly counter this by saying "most users do not use ed"

The choice to include a terminal was made at Tripos terms, where the user frontend of choice was (still) the terminal. Once this was set, it became necessary to include a "terminal emulation" in the system, which is what CON: does, actually in the given implementation as a thin interface around console (which is non-tripos, but tripos had something similar).

Yes - but there is a difference between "native terminal" and fully emulating ANSI vt220, vt420, xterm etc.

The problem here is that you confuse a bit the role of the console.device (which is one thing) with that of the console handler (CON:) which is another thing. Kingkong just hacks up the console.device, probably causing problems should it ever be upgraded. CON: is a thin layer around console. So was Newcon. ViNCEd is a self-contained handler, it does not (really) use the console.device at all.

Now I understand you are writing "Kingkong" just to mock it. How quaint.

"Most users" (and this time I include myself) do not really care much about _how_ the console/terminal/shell window is implemented. "Most users" do not even use shell much (though some of us do).

How to use ViNCEd? Do you really need a video tutorial how to run the installer? That's really all, nothing more needed.

Tutorial about how to use more advanced features to empower users. Isn't that what software is all about?

Don't make things more complicated than they are.

I have a feeling that this is exactly why ViNCEd is not so popular

Features wanted by "most users" for the console, easily accessible from a menu..
* iconify
* jump screen
* tabs
* switch to full screen mode and back
* vertical and horisontal split terminal
* prefs to configure profiles with colours, programs to start etc.

And yes - the shell should provide the tab completion.

Anyways - all these are great reasons to rather use AROS :laughing:

[guest11527]

Indeed, after playing around with it some more, IconX allows tooltypes that are otherwise ignored, I see WINDOW, STACK, USERSHELL, WAIT and DELAY. When launched using just S-bit, the tooltypes CLI and DONOTWAIT are used, and I suspect STACK too.

STACK is not a tooltype, but a fixed entry in the DiskObject. Otherwise, the differences between SYS:System/CLI, SYS:C/IconX and the workbench start are indeed minor. All of them end up in SystemTagList() to run the shell script, with one subtle difference that CLI and IconX first create a dummy CLI structure from the template in the workbench task. The workbench itself does not need to, it already has a CLI that is cloned by SystemTagList().

There are various re-implementations of IconX that are considerably more powerful than IconX. CLICon, for example, also allows arguments by selecting the "script icon" along with another icon "as argument".

[Brian]

STACK is not a tooltype, but a fixed entry in the DiskObject. Otherwise, the differences between SYS:System/CLI, SYS:C/IconX and the workbench start are indeed minor. All of them end up in SystemTagList() to run the shell script, with one subtle difference that CLI and IconX first create a dummy CLI structure from the template in the workbench task. The workbench itself does not need to, it already has a CLI that is cloned by SystemTagList().

There are various re-implementations of IconX that are considerably more powerful than IconX. CLICon, for example, also allows arguments by selecting the "script icon" along with another icon "as argument".

Do you know if there's a way to set the size of the window if you use the S-bit and start the script as a tool with "CLI" as tooltype?

I thought I might be able to just ass a line in the script execute script2 >CON:0/0/640/100/Titel/WAIT/CLOSE but that only create a new shell on top of the old one and the scripts continues with it's outputs on the first window.

[guest11527]

Do you know if there's a way to set the size of the window if you use the S-bit and start the script as a tool with "CLI" as tooltype?

There is none. The workbench computes a suitable size from the font size and the size of the workbench screen. It's always an approximate 80x16 console window

I thought I might be able to just ass a line in the script execute script2 >CON:0/0/640/100/Titel/WAIT/CLOSE but that only create a new shell on top of the old one and the scripts continues with it's outputs on the first window.

Correct. If you need this, use CLICon or IconX. The former allows many more options.

[guest11527]

It's like getting a 7 course meal when all you wanted was a cup of coffee.

If the 7 course meal is the same price as the cup of coffee, what would I pick?

This is about functionality - by putting KingCON in kickstart, tab completion and various other features are there also when booting without startup-sequence, or when booting to other filesystems (floppies, games etc).

Is there any way to have ViNCEd available like this? I think not.

No, there is not, and even if there would, it's not supposed to be a ROM component. It's your friendly shell, not the boot shell which you barely see anyhow. That's not the envisioned use case.

Anyways, there is much more. xterm also does vt420 and has its own extensions, such as the color255. If you look at modern implementations such as iTerm on and others for Linux and BSD etc, that can also output graphics directly to the terminal window.

And xterm has a textronics (sp?) emulation in it. (-: It still doesn't make this a very popular feature. If you want truecolor support in ViNCEd - it's all there, 24 bit colors.

Anyhow, at some point one has to draw a line between "useful" and "useless", and I don't see much use for 256 colors in a console. Colored text - yes, useful for highlighting. More than a handfull of colors? No, not at all. A console is not a paiting program, and neither a plotting program (even though xterm actually is).

It has already been done. MorphOS's terminal MUI class does this.

That's good for them. Though again, if you need a UTF-8 console, you're probably better of with your average Linux or Windows machine. On an Os that does not have UTF fonts, nor a graphics system that supports them, this sounds as useful as having an 8-channel Dolby surround sound stereo in a Beetle.

Let me just shortly counter this by saying "most users do not use ed"

Likely, it's a terrible editor. Though you asked "why does the system need a terminal emulator", and the answer is "because there was historically need for a terminal". If you would want to re-invent the machine, I wouldn't probably start from BCPL or Tripos either, but that's how it is. Besides, it's not really such a bad choice either given that even modern systems come with a terminal emulation (as in: Windows, Linux and even MacOs).

Yes - but there is a difference between "native terminal" and fully emulating ANSI vt220, vt420, xterm etc.

Actually, it's not really that much of a difference. Emulation of vt220 was quite useful back then, IOW, I did have a use case for that. Unfortunately, there is no working ssh implementation left, so this use case went away. It was neither very hard to add, really.

"Most users" (and this time I include myself) do not really care much about _how_ the console/terminal/shell window is implemented. "Most users" do not even use shell much (though some of us do).

Certainly. Though, I do. It seems silly to push consoles around (which I even do on my Linux machines), but I'm much faster with the keyboard than the mouse. Ten finger typing. Again "I have a use case for the shell".

Tutorial about how to use more advanced features to empower users. Isn't that what software is all about?

Oh, it is, but there is a difference between "helping users" and "spoon feeding". I do my very best to supply answers to every possible question. There is a structured manual, and there is a setup-system with an online-help system, and an installer. That's even much more than you get with most average software. A video - how would you even play this on a 68K system with at most 50Mhz? C'mon, you're asking really a bit much here.

Features wanted by "most users" for the console, easily accessible from a menu..
* iconify
* jump screen
* tabs
* switch to full screen mode and back

That's all there.

* vertical and horisontal split terminal

This is not there. Tabs (not in the sense of tab expansion) would be nice. "Screens" in the sense of the Linux program of the same name are possible (the necessary CSI sequences for that are implemented, IIRC, the 3.9 "more" even uses them).

* prefs to configure profiles with colours, programs to start etc.

That's also there.

And yes - the shell should provide the tab completion.

Really a matter of the shell, yes. Actually, pretty much anything for that is prepared, there is just too much other stuff I'm busy with. Once I get this working in the shell, a lot of old junk from ViNCed can actually go away, but that would require probably two/three month of ongoing work, spare time I simply do not have.

Anyways - all these are great reasons to rather use AROS :laughing:

Amiga is for me a retro platform. Why someone wants to implement old design errors in a new operating system is probably beyond me. But it's a free world, if you want to waste your time there, be my guest...

[Brian]

There is none. The workbench computes a suitable size from the font size and the size of the workbench screen. It's always an approximate 80x16 console window


Correct. If you need this, use CLICon or IconX. The former allows many more options.

I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't.

[guest11527]

I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't.

You cannot even start the workbench by only relying on what's in ROM (note that at least "LoadWB" is disk-based), so I wonder why this is a useful criterion.

[Brian]

You cannot even start the workbench by only relying on what's in ROM (note that at least "LoadWB" is disk-based), so I wonder why this is a useful criterion.

I know that but I have a floppy that start an extremely minimalistic workbench and includes a DOS script as an install option. I'd love to be able to start that script without rely on IconX or Execute to be present, that way I can be sure it'll start no matter what device or floppy you boot from... however the shell need to be in full screen and I don't want to force the user to manually do that.

Just looking into what options I have.
1) Ignore and accept that it'll fail in the cases where user boot from a different floppy.
2) Put IconX and Execute on the floppy, however if not in the same device (say they use DF1) it'll still fail.
3) Rely solely on ROM based alternatives (doesn't seem to be possible)
4) Rely ROM based alternative in combination with 3rd party software such as CLIwindow.

[guest11527]

I know that but I have a floppy that start an extremely minimalistic workbench and includes a DOS script as an install option. I'd love to be able to start that script without rely on IconX or Execute to be present, that way I can be sure it'll start no matter what device or floppy you boot from... however the shell need to be in full screen and I don't want to force the user to manually do that.

Frankly, if installation is your problem, write an installer script. Yes, that is disk-based, but my experience is:

No matter what you do, some user will screw up. Offer something that is known and convenient for 90% of the users. 10% will complain no matter what you do (and unfortunately, you will only receive feedback from them, positive feedback is rare), so address the 90% as good as you can, with the tools they know. That's the installer.

[paul1981]

I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't.

There is, it's called the Startup-Sequence. If you wanted to, you could still load Workbench and keep the AmigaDOS shell open by omitting the EndCLI after LoadWB. That is, I'm assuming your floppy is bootable?

[Brian]

Frankly, if installation is your problem, write an installer script. Yes, that is disk-based, but my experience is:

No matter what you do, some user will screw up. Offer something that is known and convenient for 90% of the users. 10% will complain no matter what you do (and unfortunately, you will only receive feedback from them, positive feedback is rare), so address the 90% as good as you can, with the tools they know. That's the installer.

The script is quite foolproof and req. minimal input from the user and I opted for a DOS script to save space and memory (everything is archived, even bootfiles and install tools/script, and are extracted to RAM: on startup).

All I want to know is if there's a way to start the script in fullscreen from Workbench without IconX and the answer is nya... it doesn't exist in ROM, it doesn't even exist in other OS3.x files so I'd have to resort to a 3rd party tool for this and although it would solve the issue if someone try start the script when IconX isn't present I'm not sure I have the extra 2.5KB space for the extra tool. I'll have to wait and see how my project evolves.

There is, it's called the Startup-Sequence. If you wanted to, you could still load Workbench and keep the AmigaDOS shell open by omitting the EndCLI after LoadWB. That is, I'm assuming your floppy is bootable?

I understand how you're thinking and it could have been a good idea if it wasn't for the fact that Install isn't the only function of the disk and one of the others have to be started from it's icon in Workbench to work... so for a cleaner look everything goes through Workbench. But I do like your outside the box thinking.

[Thomas]

I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't.

You could do this with two scripts. You double click on script1 which contains just this:

Code: [Select]


newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2