Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony Poprzednia 1 … 6 7 8 9 10 … 14 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Me neither. It would make SC feel a poor-relative of the likes of NC or TC. In addition I find the scrolling speed quite okay, one should try speeding up KEYREP setting in SC.INI, which makes scrolling much more responsive, animation speed is fine by me. And if someone needs ultra-quick scrolling down through tons of files, should use PG DN combination anyway.
Dbl post from my phone again, weird. Sorry for that :/
Ostatnio edytowany przez Jacques (2013-02-15 00:02:03)
Good point regarding PG UP/DN. The paged approach makes more sense in a multi-column display (such as TLW in 80 column mode), I suppose.
As for the scrolling speed, for starters I would suggest to compare not with the NC running on a 486, but with ICD's MENU - which, by the way, has only 10 lines to scroll, not 20.
When writing such a file manager for 8-bit compromises must be done between speed, limits imposed on the file system, and the amount of remaining free memory for operations such as copy. I choose not to impose arbitrary limits on directory length (256 files? Ok, why not 257?) and make as much memory free for copying buffer as possible. And I am not so sure that I've done this at speed compromise. Of course, with VBXE the blitter can be used to copy the screen contents (and this is planned), which will probably add some speed to the scrolling, but I suspect that it won't add as much as some of you (Candle) might expect, because scrolling up/down the actual screen contents is not the only thing involved in the process.
Ostatnio edytowany przez drac030 (2013-02-15 15:47:07)
tak sobie napiszę, co by się przydało (być może) a przydatność pomysłu Draco oceń sam ;)-
Czy trudnym by było dodać aktualizację "KB FREE" w czasie kopiowania, powiedzmy co 5 skopiowany plik? Chodzi o to, by nie robić tego co chwile co w momencie kopiowania małych plików mogłoby spowodować bezsensowne straty czasu?
Czy istnieje dodania opcji np. takiej, jak w TC -> po naciśnięciu spacji na katalogu otrzymujemy ilość danych zapisanych w katalogu? Niejednokrotnie kopiując większą ilość danych muszę sprawdzać odpalając CAR:MENU by sprawdzić, ile danych siedzi w katalogu/podkatalogach i na tej podstawie wiem, czy mi się coś zmieści na dysk docelowy, czy nie.
... no i kiedy kolorki pod VBXE ;)
As for the scrolling speed, for starters I would suggest to compare not with the NC running on a 486, but with ICD's MENU - which, by the way, has only 10 lines to scroll, not 20.
No defense required: the main source of surprise was merely that S_VBXE doesn't fill a column noticeably faster than RC_GR8. I'd assume the software mode to be more CPU-intensive, but perhaps this is merely a testament to how staggeringly efficient the soft-driver is. :)
I choose not to impose arbitrary limits on directory length (256 files? Ok, why not 257?)...
Really - let's not feign ingenuousness: the value wasn't picked from a hat. 256 is the extent of 6502 indexed addressing.
...scrolling up/down the actual screen contents is not the only thing involved in the process.
If a complete directory isn't held in RAM, obviously portions of same are shuffled in when they come into view. But one would assume all twenty visible names are held in RAM while they're painted on the screen.
Czy trudnym by było dodać aktualizację "KB FREE" w czasie kopiowania, powiedzmy co 5 skopiowany plik? Chodzi o to, by nie robić tego co chwile co w momencie kopiowania małych plików mogłoby spowodować bezsensowne straty czasu?
To chyba nie spowoduje dużej straty czasu, zobaczę.
Czy istnieje dodania opcji np. takiej, jak w TC -> po naciśnięciu spacji na katalogu otrzymujemy ilość danych zapisanych w katalogu? Niejednokrotnie kopiując większą ilość danych muszę sprawdzać odpalając CAR:MENU by sprawdzić, ile danych siedzi w katalogu/podkatalogach i na tej podstawie wiem, czy mi się coś zmieści na dysk docelowy, czy nie.
No to już nie jest takie trywialne, bo oznacza rekursywny skan katalogu. Pomyślę.
... no i kiedy kolorki pod VBXE ;)
Wszystko w swoim czasie :P
No defense required: the main source of surprise was merely that S_VBXE doesn't fill a column noticeably faster than RC_GR8. I'd assume the software mode to be more CPU-intensive, but perhaps this is merely a testament to how staggeringly efficient the soft-driver is. :)
In fact, the screen redraws are nearly 2,5 times faster with S_VBXE than with RC_GR8.
Really - let's not feign ingenuousness: the value wasn't picked from a hat. 256 is the extent of 6502 indexed addressing.
Let's assume that "256" looks vaguely familiar and I can imagine where it was picked from :P The question was different: if already such a number of files per directory is to be handled, why not one more? There is no such limit in SpartaDOS, so why the user has to keep a cautious eye on not copying certain numberof files to a directory, especially if a much greater number is allowed? And if he does copy a 257th file, what then?
A file manager's purpose is to facilitate maintaining of the file system. Large directories are most difficult to handle, yet I have to deprive an user of this assistance just to amuse him with sorted directories? Well, I don't think so.
If a complete directory isn't held in RAM, obviously portions of same are shuffled in when they come into view. But one would assume all twenty visible names are held in RAM while they're painted on the screen.
So let's assume that. But this is a scroll, so one place must be filled with new entry. This involves reading it from the disk - and not necessarily the one, which physically is immediately following the last displayed entry - then formatting it, then displaying. So, it of course will always consume more CPU time than simple cursor movement, without a scroll.
Ostatnio edytowany przez drac030 (2013-02-15 23:01:00)
Funkcja Move wydaje się nie działać. Zaznaczam pliki do przesunięcia, daję CTRL+M, zatwierdzam, coś się nawet dzieje (mieli), a potem nie ma żadnego efektu, tzn. pozostaje stan wyjściowy (a raczej wejściowy ;) ).
Ostatnio edytowany przez Jacques (2013-02-16 00:13:50)
Sprawdziłem na szybko, u mnie działa. Upewnij się, że plików źródłowych nie ma aby w katalogu docelowym - jeśli są, zostaną pominięte.
Były w docelowym. Ale jest jakiś powód by przeniesienie nie zadzialalo, a te w docelowym nie zostały zwyczajnie nadpisane?
Były w docelowym. Ale jest jakiś powód by przeniesienie nie zadzialalo, a te w docelowym nie zostały zwyczajnie nadpisane?
jeśli są, zostaną pominięte.
;)-
Czyli jak rozumiem te, których w docelowym nie ma przy operacji move ze źródła zostaną usunięte.
slabe by to bylo, chyba ze weryfikowana jest zawartosc i masz pewnosc ze w docelowym miejscu masz ten sam content.
drac816: dorobisz mozliwosc nadpisywania?
Praktycznie to najbardziej optymalnym rozwiązaniem jest zapytanie ze strony programu, czy nadpisywać czy nie.
zrobilibyscie porządnego szela typu bash/ksh/csh :) a nie jakies komandery :)
Wcześniejsze wersje po prostu nadpisywały, ale uznałem, że tak jest bezpieczniej. To oczywiście tylko tymczasowe rozwiązanie, docelowo będzie pytanie, czy nadpisać.
syscall: masz command.com przecież, czego mu brakuje? :)
kolorowego propmta! ;) i equalizerow! ;)
Skoro kopiowanie nie pyta czy nadpisać, to w sumie move też by moglo nadpisać (dopóki nie będzie pytania dodanego). Bo tak nie dzieje się nic i nie wiadomo o co chodzi ;) a co tu chronić specjalnie przy move...
ładnie SC wygląda z ramkami takimi, jak w QuickAssembler ;)- jak by się komuś chciało, to jest to odpowiednio (w SC.INI):
FRAMES= CTRL+: F, M, G, V, B, G, N, F
;)-
Ha, jeszcze jednak kwestia:
- otóż po uruchomieniu SC w trybie 80 znakowym na VBXE podgląd pliku (CTRL+V) odbywa się w trybie 80 znaków. Wystarczy jednak uruchomić program z przełączeniem na 40 znaków i powrócić do SC, by każdy następny podgląd odbywał się w trybie 40 znakowym. Da się to zrobić tak, by podgląd odbywał się zawsze w trybie 80?
Podobna kwestia z zapytaniem w stosunku do RC_GR8.SYS. Czy z pomocą tego sterownika dało by się pod SC pliki tekstowe podglądnąć w trybie 80-znakowym?
Draco - odpal sobie w ED SC.INI i spróbuj narysować ramki ;)-
Ostatnio edytowany przez Pin (2013-02-16 19:56:10)
- otóż po uruchomieniu SC w trybie 80 znakowym na VBXE podgląd pliku (CTRL+V) odbywa się w trybie 80 znaków. Wystarczy jednak uruchomić program z przełączeniem na 40 znaków i powrócić do SC, by każdy następny podgląd odbywał się w trybie 40 znakowym.
Z tego, co widzę, nieprawdą jest, jakoby :P Żeby tak było, jak piszesz, uruchomiony program musi zrobić reset - to wyłącza 80-kolumnową konsolę.
Albo może powiedz bliżej, jakie czynności mam wykonać, żeby odtworzyć ten efekt u mnie.
Da się to zrobić tak, by podgląd odbywał się zawsze w trybie 80?
SC stara się utrzymać ustawienia konsoli takie, jakie były przy pierwszym uruchomieniu.
Podobna kwestia z zapytaniem w stosunku do RC_GR8.SYS. Czy z pomocą tego sterownika dało by się pod SC pliki tekstowe podglądnąć w trybie 80-znakowym?
Powinno wystarczyć, jeśli dorzucisz do niego CON.SYS.
Draco - odpal sobie w ED SC.INI i spróbuj narysować ramki ;)-
A ty myślisz, że różne rodzaje ramek, jakie były wpisane w dystrybucyjny SC.INI, czym innym zrobiłem, jak nie ED-em? :P
Z tego, co widzę, nieprawdą jest, jakoby :P Żeby tak było, jak piszesz, uruchomiony program musi zrobić reset - to wyłącza 80-kolumnową konsolę.
Mamy np. tryb VBXE 80 znakowy. Teraz dla przykładu chcę wyedytować plik tekstowy, ustawiam więc kursor na pliku i trzymając shift odpalam (poprzez runext) edycję. Trzymam shift dlatego, że ED nie przełączy ekranu z 80 do 40 znaków a edytor ED w 80 znakach nie zadziała. Odpala się ED z edytowanym plikiem. Wracamy teraz do SC i robimy podgląd innego pliku, lecz już poprzez CTRL+V.
Ta sama kwestia odnosi się do byle programu odpalonego ze SHIFT i jednocześnie programu, który posiada możliwość powrotu do DOS, czyli w tym przypadku do SC. Każdy następujący podgląd (ctrl+V) odbędzie się tym samym w trybie 40 znakowym.
A ty myślisz, że różne rodzaje ramek, jakie były wpisane w dystrybucyjny SC.INI, czym innym zrobiłem, jak nie ED-em? tongue
Ctrl + E przesuwa mi pod ED'em kursor na koniec dokumentu. CTRL+E to jedna ze składowych części ramki. Jak więc wyłączyć w ED funkcje do przenoszenia kursora w określone miejsce? :P Mam nadzieję, że do obsługi edytora nie trzeba czytać instrukcji ..... ;)
Ostatnio edytowany przez Pin (2013-02-16 20:28:17)
Mamy np. tryb VBXE 80 znakowy. Teraz dla przykładu chcę wyedytować plik tekstowy, ustawiam więc kursor na pliku i trzymając shift odpalam (poprzez runext) edycję. Trzymam shift dlatego, że ED nie przełączy ekranu z 80 do 40 znaków a edytor ED w 80 znakach nie zadziała. Odpala się ED z edytowanym plikiem. Wracamy teraz do SC i robimy podgląd innego pliku, lecz już poprzez CTRL+V.
A nie wystarczy najechać kursorem na plik i nacisnąć Ctrl/E?
Ta sama kwestia odnosi się do byle programu odpalonego ze SHIFT i jednocześnie programu, który posiada możliwość powrotu do DOS, czyli w tym przypadku do SC. Każdy następujący podgląd (ctrl+V) odbędzie się tym samym w trybie 40 znakowym.
Nie potwierdzam, u mnie każdy następny podgląd jest w trybie 80-kolumnowym. Sprawdź, czy zapisywany jest plik SAV (po czasie i dacie).
Mam nadzieję, że do obsługi edytora nie trzeba czytać instrukcji ..... ;)
Chyba trzeba ... RTFM :P
ok - teraz widzę, że wersja SC 0.8.8 działa pod tym względem lepiej :) Ok ;)
Zobacz zatem, czy to działa (bo SOA#1). Z nowości tylko aktualizacja "KB free" podczas kopiowania.
EDIT: archiwum uaktualnione (wymieniłem SC.COM).
Ostatnio edytowany przez drac030 (2013-02-17 02:28:47)
o - :) - już sobie zabieram
Całkiem ładnie to działa, przyznam ;)-
Ostatnio edytowany przez Pin (2013-02-17 01:04:12)
Strony Poprzednia 1 … 6 7 8 9 10 … 14 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.118 sekund, wykonano 14 zapytań ]