Yokemate of Keyboards
Posts: 2136 from 2003/2/24
From: po-RNO
Quote:
connor wrote:
This is what I’m saying. You always have big programs because of they are made with Hollywood, even if they have very tiny functionality. Yes, most disks are large enough today. But is this a reason to waste the space?
Well, what can we do then? It's a compromise if a coder wants to use this kind of safe higher level language with easy multiplatform support. I as a programmer can't affect to the minimum executable size Hollywood creates, and there is no alternative for what I want. None of my programs would exist without Hollywood, so I guess you just have to take or leave it. If it's not good enough for you, don't use the programs... or make better ones yourself.
Quote:
Amiga/MorphOS was always tiny and fast, also because of its small size. A 2MB file loads longer than a 200kb file. And look at similar software on MorphOS. For example look how small JukeBox is. Or compare Vpdf with RNOPDF. Vpdf is smaller and faster.
Well... it's hard to say exact sizes if you count all the libraries they're using. JukeBox outsources almost everything to Reggae and is quite minimal player, but for example RNOTunes supports much more formats (through ffmpeg etc. plugins) and has graphical gimmicks etc.. RNOTunes can't use Reggae, because Reggae is not available on any other platform but MorphOS.
How would you like to compare VPDF and RNOPDF sizes? If you look purely at the executable size, VPDF is about 7 MB and RNOPDF is about 3 MB. If you count all resources they're using, I don't think the difference is that big.
The more modern libaries and other resources you're using, the bigger sizes become. Bedroom coders can't do everything alone anymore and you'll have to use modern open source components more and more to keep up. Wayfarer is more than 30 MB, while IBrowse is about 1 MB... but which one is more useful?
Quote:
I don't know how it affects the speed. I just see THAT it does. My disk does not look very fragmented in the defrag tool. And other programs load much faster because they are much smaller. But I also don't know how it would be with a 3MB program that is not written in Hollywood.
I made a test executable of RNOPDF which opens the program and quits immediately. Then I used the Time command in shell to measure time to launch and quit the program. It took 0.2 seconds on my Mac mini with an SSD drive. So it shouldn't be about Hollywood itself I think, because the program opens so quickly in this case.
Quote:
I don’t know how they do it, too. Or if it depends on the programmer or Hollywood. I would think Hollywood because I just observe it with every Hollywood MUI program that I try. This is why I usually not try or use them: because they act so slow. Just when I remove the size a bit or move the windows around the CPU meter already goes up and the windows and redraw start to lag. But not with non-Hollywood programs. Slow are for example RNOPDF or RNOEffects or also Sqlman. Or Mediathek: http://evil.bplaced.net/index.php?name=Mediathek&page=AboutIf there is anything I could look for then please tell me.
RNOPDF is not using MUI, so a MUI connection is a false alarm then.
Quote:
Ah, I didn’t know that. And I didn’t read which other Hollywood programs use it. Hopefully Hollywood will support MUI5 one day.
Yeah, well, the line between MUI 4 and 5 is a bit shady... I don't think there was such a feature jump, but it was rather a version numbering thing :) In any case all MUI apps have better user experience when the actual installed MUI system is newer than the ancient 3.8.
Quote:
Okay, it does not crash the OS, that’s true. But when something went wrong and it is unsafed, then you immediately lose it, for example searches in the Mediathek program. Then you cannot even copy and paste the text which would still work in some other programs. The exit of those programs reminds me of Amiga Basic or Rexx programs.
As said, I rather take that than crash the whole OS and lose all open projects from other programs too. But as with any programs, regular saving is your friend. And of cource applications should be well tested to avoid these situations in the first place. Coders should also think when they should save any critical data that is needed later. Just give feedback to the coders when you find any issues, to make the programs better, because users shouldn't be thinking things like this when programs are well made.
Quote:Quote:
But that said, a programmer can also disable the internal error handler in Hollywood if wanted (permanently or temporarily) and let the mess escalate, or write your own error handling function. For example, I have made my own error handling function in RNOPublisher, and if a fatal error occurs, it doesn't quit immediately but writes a backup file of the current project before exiting, and informs a user about it.
And is that more stable or faster or user-friendly? At least it sounds better. I do not use the publisher much because my main feature would be to import and edit an existing PDF file. These it cannot load.
Code quality makes a program stable, it's not related to a programming language, but in the case of bugs, it's more user-friendly to not lose the unsaved projects. BTW. I have similar error handling in RNOEffects too, and maybe somewhere else I don't remember now. I wonder if these have saved any projects on anyone? :) At least I haven't got any related bug reports...
Quote:
About the UI of Hollywood programs: Moving around program windows fast can raise the CPU very high, often more than 50% or up to 100%.
I just can't see the difference. I opened RNOPublisher and then opened Ambient's "My MorphOS" window, and resized it to the same size with the RNOPublisher window (it's important to compare windows with same dimensions). Then I grabbed them both from the window title bar with the left mouse button and tried to move windows as fast as I can. Both make similar CPU load... there's no difference.
Quote:
For example the empty RNOPublisher main window. When I resize the window and hold the right corner clicked and move it then often the window stucks in a small place on the left side although I did not reliese the mouse button. CPU goes to ca. 50%. When I click right mouse button to cancel the window size, it restores the original size, the program reacts again and the CPU load goes down. Yes, it is not the standard usage of a window to move it around for long but it shows very simple how sluggy Hollywood ( MUI) programs are. And every other program that I do the same to (IBrowse, Iris, Wayfarer …) do not have this delay.
I can't reproduce this behaviour. Can you test with a simplier program without a graphical display on it (just standard MUI objects), like RNOArchive for example?
