This does not refer to the actual translation, but to the text not being adapted when the language is switched in the preferences. The correct text shows up after a restart of the program. For the other tooltips it's OK.

Oh I see what you mean, tooltip text doesn't change to the new language after the language is switched and the UI is re-rendered, I confirmed that and will look into it.

Well, can you explain it then, as far as I understand you want AspeQt to emulate the Turbo1050, and I am sorry but i don't really understand why? Why AspeQt needs to emulate a Turbo1050? the software is a generic high-speed atari drive emulator, does not rely on things like sector skews or some other esoteric ways of speeding up the transfer, it solely relies on SIO speeds, so it is not an emulator in a sense that it mimics any specific hardware. Handling a variety of different disk drives is the DOS's job as far as I know. Am i not seeing something here clearly?, if so please clarify.

EDIT: Lemiel, if i can understand what you exactly need i have no problem re-opening the ticket as long as it really is AspeQt related.

version 1.0.0 Preview-2 (Feb 07, 2014)
+ Added a single slot view called Mini/Shade Mode, in this mode only one disk slot is shown and minimal screen
real estate is used. This is for users who run AspeQt mainly from a single folder or ATR. Can be toggled
through a new Window menu item or with CTRL+M key sequence. The window can be tacked away in a
corner of the screen in a semi transparent mode called Shade Mode. When the cursor is moved over the window,
it becomes fully opaque for easier viewing and returns back to semi transparent mode once the mouse cursor leaves.
All menu features are still available in this mode. Shade mode screen geometry (screen coordinates) is remembered
from session to session but AspeQt always starts in full view mode.
+ AspeQt log can now be displayed on a separate window independent from the main window. A filter option
is added to filter log items by disk id. A menu item is also added to invoke log view window in mini mode as the regular
log area is not shown to save screen space. In full view mode the same window can also be invoked by double-clicking
on the log area.
+ Re-organized menu item shortcut keys and added new ones:
CTRL+H: Hide/Show drives D9-D15
CTRL-M: Toggle Mini mode
CTRL+S: Toggle shade mode (valid/works only in Mini mode)
CTRL-L (or double click on the log area): Show a independent log window.

I'll send you the code so you can compile it for Linux, i won't make the source available in SourceForge until I am finished with version 1 as I noted earlier.

These pre-releases are for people to test it and to express their opinion, as always all feedback negative or positive is welcome. Next, I'll be tackling the ATX support which was tried before but never finalized, this time around I will use the VAPI library, then I'll finalize the image explorer which lacked support for importing new files into disk images, I'll also drop AspeQt explorer in favour of Windows Explorer for exploring Folder Images.

Is there a way to compress the log area to make the GUI "shorter?" Still takes up too much (vertical) space (IMO).

As an example, here is a shot from my desktop showing APE and my normal ATR folders with AspeQt layered on top of them. Do the "slots" really need to be so tall?

Any chance that you can either make the ATR info fonts more legible with a larger typeface. That has always been a impediment to my use -- the APE GUI is so much easier to read.

-Larry

How's this look, is it easier to read? Making fonts larger will reduce the amount of disk information visible for a given main window size, causing minimal ATR info to be visible, as you can see in the photo the effect is even worse with APE. AspeQt gives you the full path and the ATR name in tooltips and status tips, but you still have to move the cursor over to the disk slot to see the names.

I'm a little confused. When I run AspeQt I can resize the log section to any sizeI want.

You may not be using the same preview version as Larry does, so it is possible that his version may have a fixed minimum size for the log area. In any case the upcoming preview 3 is setting the minimum height for the log area to 1 line, so at least one line of log will be visible at all times.

* GUI changes for more screen space savings as follows:
- Smaller buttons
- Shorter drive designators
- Log area is shrunk to single line height, double-click on the line to open a full view log window, if the main window is re-sized, the log area can be expanded by clicking and dragging the single line (this click and drag expansion requirement may be temporary if I can figure out how to make the log area expand automatically, for some unknown reason the auto-expansion decided not to work any more, this may have to do with many re-sizing options I recently added, which may have inadvertently broke some layout rules. At this point I won't spend any more time on this as a separate re-sizable log Window is available anyway).

+ Added larger font support to the disk slot descriptions. New font size can be made permanent in the User Interface Options.

* Shade mode is now optional through a setting in the User Interface Options.

I am still looking for your suggestions on the user interface and will make small adjustments if necessary, but I will now be moving away from GUI to work on the Folder and Image explorer bits, and the addition of the VAPI support.

+Addedareloadbuttontothe"BootAtariExecutable"dialog.Thebuttonre-loadstheselectedexecutablefilebeforethe Atariisre-booted.UsefulforAtarideveloperswhousethisdialogforcontinuoustesting.Thebuttonallowsautomatic refreshof AspeQtbuffersby reloading the file withouthaving to close the dialogwhentheexecutablehaschangedbetweenAtarireboots.

Simplified the "Boot Atari Executable" dialog by removing the "Keep this dialog open" check box. The dialog will now remain open until it is exclusively closed by the Cancel and Close buttons. This update also fixes the issue of opening multiple instances of the said dialog.

The issue was not immediately apparent, and I found about it only after I posted the Preview-4 zip file above. All instances of the dialog was opening at the same exact location of the screen and only the last dialog was visible unless the dialog window is moved, revealing the previous one hidden underneath.

Ok guys some bad news from the AspeQt front.. Today I was fiddling around with FJC's uflash.xex and was having trouble to get it run from a partition on my IDE+2. SDX wasn't able to load it, giving "memory conflict" error and when tried to load it with X.COM, the flasher loaded but crashed the computer with a blank screen. My initial thought was that somehow it was not compatible with IDE+2 because I was able to run it by loading the xex file directly with AspeQt after removing IDE+2 from the computer. What I didn't pay attention at that time was that I copied the failing version of uflash.xex to the IDE+2 partition from an ATR I created with AspeQt.

About an hour after I posted a message in the uflash thread showing a video of the failure, and after seeing FJC's - not amused type reply - it downed on me that something might be wrong with the file and I compared the uflash.xex file i downloaded from his web site to the one in the ATR i've made with AspeQt. Lo and behold the two files had different lengths and closer examination with a hex editor revealed that the copy of the file in the ATR had extraneous bytes (in fact a specific value - $0D-Carriage Return character) in several places throughout the body.

My conclusion is that adding a file to an ATR image by using AspeQt explorer has problems, I have yet to examine the code - this code is from the original v0.6 of AspeQt so I am not familiar with it- and verify the problem for sure but at this point in time I can not see any other reason for those extra bytes in the xex file.

So my advise to people who use AspeQt to create/update ATR images (if any), is to stop doing that until I sort this thing out and issue an update. Also make sure to check all ATR images you created that way for possible file corruptions. This is a nasty bug which surfaced by sheer coincidence and right in the middle of other to do's in the list, but has to take precedence. So sorry for the bad news but better late than never....

About an hour after I posted a message in the uflash thread showing a video of the failure, and after seeing FJC's - not amused type reply...

Correction: "amused reply". Apologies if this wasn't apparent.

The incident should serve as a timely reminder of the perils of hair-trigger cinematography when the resulting vignettes are primarily used to draw attention to the perceived shortcomings of other people's software, especially when the shortcomings later turn out to be in one's own software; shortcomings apparently overlooked while the UI is augmented with translucent windows and other such visual niceties. Nothing wrong with bugs: the very best authors write software with bugs in them, and I have no objection to a descriptive bug report when a cinematic featurette is not absolutely required. I have no wish to impede the narrative flow of the Aspeqt monologue; I merely point out that it shouldn't have taken FJC's could-hardly-hold-the-camera-steady-for-laughing reply to instigate the troubleshooting procedure you describe in the second paragraph of post 672. This procedure is best carried out prior to unfolding the director's chair, since otherwise, the diagnosis of issues in the "official" build of Aspeqt becomes circumstantially dependent on FJC's deadpan, pragmatic response. This means that were it not for FJC's response, the latest bug in Aspeqt might not have been discovered, and the alarming upshot of this is that I have been an unwitting instrument in the "testing programme" of Aspeqt - an application I no longer use in its latest incarnations, and have no desire to test.

In short, there are less convoluted, non-cinematic ways to discover bugs: namely, the awkward business of testing. Only then can we attain the prized goal of "Solid software".

The incident should serve as a timely reminder of the perils of hair-trigger cinematography when the resulting vignettes are primarily used to draw attention to the perceived shortcomings of other people's software, especially when the shortcomings later turn out to be in one's own software; shortcomings apparently overlooked while the UI is augmented with translucent windows and other such visual niceties. Nothing wrong with bugs: the very best authors write software with bugs in them, and I have no objection to a descriptive bug report when a cinematic featurette is not absolutely required. I have no wish to impede the narrative flow of the Aspeqt monologue; I merely point out that it shouldn't have taken FJC's could-hardly-hold-the-camera-steady-for-laughing reply to instigate the troubleshooting procedure you describe in the second paragraph of post 672. This procedure is best carried out prior to unfolding the director's chair, since otherwise, the diagnosis of issues in the "official" build of Aspeqt becomes circumstantially dependent on FJC's deadpan, pragmatic response. This means that were it not for FJC's response, the latest bug in Aspeqt might not have been discovered, and the alarming upshot of this is that I have been an unwitting instrument in the "testing programme" of Aspeqt - an application I no longer use in its latest incarnations, and have no desire to test.

In short, there are less convoluted, non-cinematic ways to discover bugs: namely, the awkward business of testing. Only then can we attain the prized goal of "Solid software".

&nbsp;

I'm just a stalker here, but I would like to reply about your message.

Why do you use this kind of response? Why are you so much strong opinionated? If you have something against the author or the way of making software, then keep use the software you prefer or make your own (I cannot find one in atari8.co.uk).

Why do you write in that redundant and literary-like way? I appreciate your skills at the English language, something it's quite difficult to me as I'm not native English and my formal education was quite crappy, but I don't understand why the same message can't be written in a simpler form.

It seems you feel upset about someone saying your software was buggy, because you're too proud on it. Why people can't fail? And if the current AspeQt developer failed in the way of dealing the problem, he can now understand his wrong ways. People can learn from it's errors.

Personally, I would prefer a more universal program like AspeQt but for 8/16bit systems (both consoles and computers). I was an uCON64 user in the past and had a MDPRO from ToToTeK, I miss that kind of software integration. But I consider AspeQt quite useful, despite I'm more of a keyboard junkie (so I would prefer a ncurses frontend). But this doesn't make me to hate AspeQt or not wanting to use it.

I'm just a stalker here, but I would like to reply about your message.

Why do you use this kind of response? Why are you so much strong opinionated? If you have something against the author or the way of making software, then keep use the software you prefer or make your own (I cannot find one in atari8.co.uk).

Why do you write in that redundant and literary-like way? I appreciate your skills at the English language, something it's quite difficult to me as I'm not native English and my formal education was quite crappy, but I don't understand why the same message can't be written in a simpler form.

It seems you feel upset about someone saying your software was buggy, because you're too proud on it. Why people can't fail? And if the current AspeQt developer failed in the way of dealing the problem, he can now understand his wrong ways. People can learn from it's errors.

Personally, I would prefer a more universal program like AspeQt but for 8/16bit systems (both consoles and computers). I was an uCON64 user in the past and had a MDPRO from ToToTeK, I miss that kind of software integration. But I consider AspeQt quite useful, despite I'm more of a keyboard junkie (so I would prefer a ncurses frontend). But this doesn't make me to hate AspeQt or not wanting to use it.

This has been going on for a long time buddy, and when Ray remarks that I was "not amused" by something he posted in one of my threads, I'm perfectly at liberty to come and make my point here. As for the language: I'm certain the intended recipient will "get it".

Believe it or not, I'm not upset at all. You are simply perpetuating the myth that this matter is causing me some misery; I can assure you it is not the case. I have no objections to receiving bug reports and fixing bugs, when my software contains bugs. But I absolutely and completely stand by everything I have written in the above post, and would challenge anyone to gainsay the common-sense advice contained therein.

As for "hating" Aspeqt: I have nothing against it; the current development path simply does not meet my needs, so I don't use the software. If this somehow prevents me having an opinion when I am circumstantially involved in what has been written about, then please explain why.

Take a look at the posts where atari8warez has criticised me for not producing "solid software", or complained that said software does not behave in the way he expects. Or read up on the maddening confusion which ensued when I tried to assist with some much needed bug-fixes in Aspeqt. I have spent many hours dealing with complaints and diffidence in the past, and yesterday saw me investigating an issue which did not exist, and this because the issue had not been properly investigated in the first place. This is far from being an unprecedented event. The approach seems to be "upload a video and ask questions later". Regardless of the fact the latest video has been removed, several others remain, and the only time atari8warez publishes a video of my software or instigates communication with me is when he has a complaint to make or some problem to immortalize on film. Meanwhile, I now make efforts to keep out of his way, despite his continued participation in my threads. And yet you have a problem with the common-sense advice I provide above, which is intended to encourage the prevention of future misunderstandings?