Damned ESC key !!!
DuLac
After a week using xACE,
it is about half a dozen times that ALL work was lost by pressing (as
habit) the ESC key !!!
(it happens more often... but those OTHER times... I had made my usual
"save tt" lifeguard )
The ESC key should be a BREAK key.
CTRL is usually the SYMBOL key parallel to Upcase.
And how to get out? F12 would be just fine, as a usual one too.
This time I'll get a break myself, maybe to re-do everything again
Xeet, xeet, xeet !!!
'later.
Lawrence Woodman
I couldn't agree more and couldn't help but laugh when I saw this, I've
been there too many times. Yes it does need changing to something
else. I can see why it was chosen at the time, but now it is really
frustrating. I have opened an issue for it:
http://github.com/LawrenceWoodman/xAce/issues#issue/5
I too feel that ESC and not F12 should have the function of BREAK.
So now what to have for quiting the program. We could have ALT-F4,
which would be more standardized, though not sure how that would feel on
non AMD/Intel Unix machines. Or as you say, we could use F12. This is
all of course until we have a GUI.
bfn
Lorry
--
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com
DuLac
> I've been there too many times. Yes it does need changing to
> something else.
>I too feel that ESC and not F12 should have the function of BREAK.
> ... for quiting the program we could have ALT-F4, <...> more standard.
Check!
>though not sure how that would feel on non AMD/Intel Unix machines.
Like Gnome or XFCE.
> Or as you say, we could use F12.
CTR as ACE Symbol keys (I prefer system translation as is, but...)
NEVER as reset... as it is a much too close key...
... and reset is a much to dangerous function.
BTW: An Exit key, even F12, is much too dangerous to be used
without confirmation.
> This is all of course until we have a GUI.
On the other hand, I fancy the idea of having xACE independent of X11.
I know that won't happen. It would need VGAlib (?) instead of X11.
Using VGALIB would it be named vACE ?!? <g>
---
This may all be peanuts, but after loosing a lot of time with
vanishing work...
... I do see IT with a different perspective. It is too much true that
some
smallish things CAN be quite BIG in a terrible way...
'till.
DuLac
ESC is now BREAK
CTRs are inibited
Alt-F4 was always exit (at least in a GTK environment)
Get the changes in the ACE resource Forum.
I couldn't find a way to upload or alter in the GIT.
This way is fastest.
It was just a simple cut-and-paste.
But what a difference! : No more lost work!!!
At least not because of xACE, now only due to the ACE redefining
system.
'till,
DuLac
Lawrence Woodman
I'm looking at this now. I can't just import it wholesale because of a
few other alterations that you have made on the way, but the principle
is fine. One thing though, I have been thinking and it looks as if
CTRL-Q, would be a more suitable exit key across platforms, and just
allow ALT-F4 to keep its normal system function. I will definitely
include this in v0.4.1 as we both know from painful experience how
needed this is.
Lawrence Woodman
DuLac wrote:
>> This is all of course until we have a GUI.
>>
> Got the idea. Moving dangerous hot-key to a menu is excellent.
> On the other hand, I fancy the idea of having xACE independent of X11.
> I know that won't happen. It would need VGAlib (?) instead of X11.
> Using VGALIB would it be named vACE ?!? <g>
>
Actually SDL, would make it independent of X11 and we could still have a
GUI of sorts. Funnily enough 'vace' is another creation of Edward's, it
is an Ace emulator for windows.
bfn
Lorry
> ---
>
> This may all be peanuts, but after loosing a lot of time with
> vanishing work...
> ... I do see IT with a different perspective. It is too much true that
> some
> smallish things CAN be quite BIG in a terrible way...
>
> 'till.
>
DuLac
> I can't just import it wholesale because of a few other alterations
> that you have made on the way, but the principle is fine.
And only the printf block in the Menu followed, for obvious reasons.
'till.
DuLac
> GUI of sorts.
However, let's not forget ALLEGRO library just because not so popular
with high graphics games, and so not so popular.
SDL is too big for this small needs.
Allegro is more portable and smaller.
(The KISS rule comes handy here)
I suspect Allegro is much more interesting and is very much alive.
Example: More Ports... only needed code is compiled directly
in the executable or external library. No practical limitations vs
SDL .
That reminds me xACE and ACE32. Why use an elefant gun... to kill a
fly?
Besides, SDL dropped DOS. Allegro last version supported DOS.
New versions are mostly not needed changes (SDL type) while some
others
are structural changes to ease BIG development.
I'll keep an eye on it. The more I find, the more it seems the right
choice.
For it's size... and for (expected) easiness in finding the right
function.
I would suggest a good comparison between the two options after
getting
xACE right. Popularity is not a good criterion to make an efficient
choice.
What are the criterion ? Efficiency, Ease, Size. (My thoughts)
It had to be pointed out while no compromises have been made.
'till,
Lawrence Woodman
Unfortunately some code relating to the spooling hook was also removed,
I guess by accident when you were re-jigging things. Anyway I have made
the alterations and pushed the changes to GitHub and made reference to
your contribution in the commit message.
Many thanks
Lawrence Woodman
I have renamed the subject.
DuLac wrote:
> However, let's not forget ALLEGRO library just because not so popular
> with high graphics games, and so not so popular.
>
> SDL is too big for this small needs.
> Allegro is more portable and smaller.
> (The KISS rule comes handy here)
>
> I suspect Allegro is much more interesting and is very much alive.
> Example: More Ports... only needed code is compiled directly
> in the executable or external library. No practical limitations vs
> SDL .
>
I too favour smaller, simpler libraries. As far as ports are concerned,
I think that SDL has the edge, and am sure that it will be made
available quickly on more handheld devices and tablets than Allegro will.
> Besides, SDL dropped DOS. Allegro last version supported DOS.
>
I have just looked at the Allegro project page and it has now dropped
DOS too.
> Popularity is not a good criterion to make an efficient
> choice.
>
To a certain extent I agree, but having said that, it looks like SDL
will be fairly well supported for quite some time to come, so it at
least should prevent another rewrite if the graphics library becomes
outdated. Either way, we need to way up the alternatives properly
before proceeding further.
bfn
Lorry