The above video goes away if you are a member and logged in, so log in now!
Correct. But the real safety feature is that the definition of the Select button itself can NOT be altered from within the config menus of uLaunchELF itself, to make it impossible to lose configurability by mistake.
Originally Posted by zabolyx
Note that a conflict over the name to be used for the new function caused two releases (including the latest) to have an incorrect name in the supplied CNF file. This did cause some users to lose configurability through the normal button. That issue, and how to fix it, is addressed in greater detail in a following post.
It can only be changed by editing LAUNCHELF.CNF and adding a new value for the variable "LK_Select_E1", to define what effect it should have. The default value would be "MISC/Configure", but by default this is assumed even when the variable is missing (as it always will be in CNFs from older versions).
If you don't set this variable by manually editing the CNF, then it will never be created, and the default behaviour will then remain as-is. But once you have created this variable, then it will be 'passed on' to each new CNF saved to MC, so you never have to edit it again (unless you really want to change it of course).
Similar rules apply to the other two CNF-related buttons that can now be programmed by the user, using the new variables "LK_Left_E1" and "LK_Right_E1" in the CNF file. Adding new entries for them allows you to choose new actions for the D-Pad 'Left' and 'Right' buttons in uLaunchELF, to replace the old defaults that simply switch between multiple CNFs. This is particularly useful when you only have one CNF page, but want a couple more command buttons.
Another reason for modifying the settings for the three CNF-related buttons is when you are making a "child-safe" installation. If you don't want a new definition for these buttons, then you can just define them to have no value at all, by adding these three lines to your CNF:
That will disable the internal defaults for those keys without adding any new link.
Whenever you have modified the LK_*_E1 variables for any of those keys, you should also remember to modify the corresponding LK_*_Title variables too. If you just disabled the keys, then the titles should be defined as empty strings, but if you used them for new purposes, then the titles should indicate this, so if you defined execution links like in these three example lines:
LK_Select_E1 = hdd0:/+ELFS/SMS/SMS.ELF
LK_Left_E1 = mass:/Emulators/InfoGB/InfoGB.ELF
LK_Right_E1 = mass:/Emulators/InfoNES/InfoNES.ELF
Then you should define some descriptive titles, like in these three example lines:
LK_Select_Title = Simple Media System
LK_Left_Title = GameBoy Emulator
LK_Right_Title = NES Emulator
Much of the above is also (very briefly) described in the commented LAUNCHELF.CNF supplied in the release ZIP of v3.78 and later versions.
Best regards: dlanor
Last edited by dlanor; 07-05-2006 at 03:56 PM.
Some news from jpg viewer.
So, 4kb for full jpg viewer, or 7kb for the same with tumbnail mode.
What is slideshow? Is diaporama same thing? Because it's ok with timer and transition off, zoom, fond, zoom+fond, repeate a folder...
So, now we are waiting for Dlanor, EP, approbation.
And if they don't want it, i keep it for me.
Again a little video for fun, to show you.
Last edited by Polo35; 07-30-2006 at 07:19 AM.
Well, not with any high priority anyway, but I'm not opposed to it either.
Originally Posted by Polo35
This does make a simple viewer very cheap to add, both in runtime resources and in development work needed.
But considering jpg stuff is allready implemented.
Advanced image viewing is a science of its own, almost anyway, and we needn't go overboard with new functionality of that kind. For starters I'd go for just simple circular slideshow functionality, with time-per-pic as the only configurable option (including fully manual setting), and no advanced transitions. Anything beyond that would be luxuries. (I'm not opposed, but see no need to prioritize them.)
That may only take ~4 more kb,
for a full viewer with zoom, motion, folder playing, repeat, timer, transition, full screen, etc, ...
Another thing I'd like to add soon is a simple one-pic viewer to be used for alternate launching in the browser, when selecting a JPG. I'd also like to do the same for text files using your text editor. But this requires two major changes first. We'll need to add some way of associating file types with a launched program, and we really should think up a good way to use external programs with arguments too, for that kind of launching (by selecting associated data files I mean). But I'm not sure which programs (if any!) support extra arguments...
I'm in favour of it, within reasonable limits.
, why not ?
What do you think Dlanor, EP ?
Best regards: dlanor
You probably made the mistake of including the LAUNCHELF.CNF file when you installed v3.78. Correct ?
Originally Posted by Poose22
That file is only intended as an example for you to study, as it contains extensive comments on all the variables such a file may contain. But the normal first installation should NOT include it (or any other CNF file), but fall back on defaults instead. Then you should use the config menus to make your own initial settings, and as you exit back to main menu your setup will be saved.
This saving will always be made to "mc0:/SYS-CONF/LAUNCHELF.CNF" when you've started uLaunchELF without a CNF present beforehand. For such cases, and when you really want a separate CNF stored with the ELF, you need to copy it to that location yourself.
Normally you should be able to start with the supplied CNF too, as that is supposed to contain all normal default settings, but there are some problems with this. One is that the file also contains some examples, for a few things that have NULL defaults (empty strings). Another problem is that one default of v3.78 was so heavily rejected by the user group that it was changed for v3.79, and unfortunately that change was not also made in the CNF supplied with v3.79.
Because of that rejection, and that mistake, the CNF supplied both with v3.78 and v3.79 contain a supposedly 'default' setting "LK_Select_E1 = MISC/Configurator", even though that is no longer valid in v3.79, where the correct 'default' value of that variable is "MISC/Configure".
You can fix this by either removing the CNF and starting 'clean'
, or by editing the CNF file to change "Configurator" to "Configure", or even by erasing the line definining the "LK_Select_E1" variable. Either method should eliminate your problem.
Best regards: dlanor
yes i may have included the LAUNCHELF.CNF file when i installed 3.78. but i did as u stated in ur post and it has fixed my problem. thanx a bunch for your help and time
Originally Posted by dlanor
he he best wishes for the final
I'm very much in favor of this feature! Thanks once again Polo35!!!!
Originally Posted by dlanor
I made some change in libjpg, to see if that solved the unsupported jpg problem.
In a first time i tried to remove some marker error check.
With that change, unsupported jpg problem is solved.
But old unsupported pic are drawn with a very bad quality.
So, i'm going to port the optimize tool now, replace marker error check, and report what happen.
Edit: HO, HO.
The optimize jpg tool decompress jpg to a file and recompress it to an other.
The problem is, i don't want to use a temp file created in mc or hdd, and there is no tmpfile fonction (fonction which create a temp file in ram )implemented in libc for the moment.
So, i've to implement some stuff in libc to acces tmpfile fonction.
That may take some more time.
Last edited by Polo35; 07-07-2006 at 02:31 PM.