RetroFE forums

I'm glad it works. But that code block is an older commit than this:

void Configuration::initialize()
{
    const char *environment = std::getenv("RETROFE_PATH");
    std::string home_load = std::getenv("HOME") + std::string("/.retrofe");
    std::ifstream retrofe_path(home_load.c_str());
    // Check Environment for path
    if (environment != NULL)
    {
        absolutePath = environment;
    }
    // Or check for home based flat file works on linux/mac
    else if (retrofe_path && std::getline( retrofe_path, absolutePath ))
    {
    retrofe_path.close();
    }
    // Or check executable for path

This should pass if no .retrofe file was made at least. Can you check? Thanks for the help.

Does retrofe.exe quit immediately at the command prompt for Windows or if you click it?

I appreciate that more of you are testing things out for windows. Sorry guys with the holidays I haven't had time to look further into this but if RetroFE is exiting quietly upon start, it sounds much like what happened to me when I 1st tried to figure out RetroFE for Mac on the original code base.

As a quick sanity check try setting or even unsetting RETROFE_PATH environment variable to where your RetroFE Base folder is before starting retrofe up. If it works then a minor tweak is probably needed in the configuration initialization checks.

The configuration assigns an absolute path by 1st checking: if ENV is set, or a hidden Text File is read, or get path relative to Executable.

Long story short see original: Source/Database/Configuration.cpp

RetroFE quietly exits on Configuration path initialize failures if it can't find the environment var RETROFE_PATH or if can't access the base folder relative to executable. Mac doesn't have /proc/[pid#]/exe for proc pid path. So it would fail to start for me.

So I added changes to fix how mac get's the path relative to the executable but it also supports the legacy RETROFE_PATH check. Do people really depend on this? The trouble is if you mouse click RetroFE as an app/GUI and not run from the command line your version of OS may need to load RETROFE_PATH by other means than shell. As a workaround I included a hidden file option in users HOME/.retrofe, untested in Windows. The .retrofe file is a text file with only the "base folder path" stored, no var name, no spaces, as noted in the Readme.md / Overview.

That's assuming something is up with the Configuration for Windows. Maybe we should drop these optional checks. I just don't know the history behind RETROFE_PATH.

This may not be related. I don't know if this is a side effect of replacing an old retrefe build layout with a newer retrofe executable but the Carousel 16x9 layout's wheel will load all the old artwork if you enter "Genesis" and then exit back to main. Zero Tolerance will still be showing as choices inside the main menu. It's as though a wipe of the last artwork was skipped.

Note: this theme wasn't updated to group it's media inside images, sounds, fonts, videos folders as in the later retreofe builds. If there are newer updates to these themes I'd like to know where I can download them.

I'm reminded of this in the old forum. I haven't used Mint linux before but it sounds strange to have the issue without a window manager up. It's like both RetroArch and RetroFE are competing for your console. The open command was real useful for me controlling the foreground swap.

I don't know but it might help to force Full Screen on RetroArch when it launches using RetroArch -f "%ITEM_FILEPATH%".... so there's no chance to try to sub window on exit.

I'm happy to contribute! The more platforms the merrier right? I just sent you a PR. 

We need some test users from the community. Maybe as people introduce themselves they can specify their platform of choice. There are definitely some unknowns out there for each platform.

Nothing major but I was checking the RetroFE logs and I notice some output about missing directories / files that may have something to do with an out of sync Package/Environment/* in bitbucket.

I ran out of time to investigate but one that stood out to me was:
/meta/hyperlist/ was in bitbucket but I didn't see /meta/mamelist in there. You see messages in the logs.

grep not log.txt
[2016-12-22 07:36:11] [INFO] [Configuration] Could not open /usr/local/Cellar/retrofe/0.7.20/collections/Main/info.conf"
[2016-12-22 07:36:13] [ERROR] [CollectionInfoBuilder] Could not read directory "/usr/local/Cellar/retrofe/0.7.20/meta/mamelist"
[2016-12-22 07:36:18] [INFO] [CollectionInfoBuilder] Could not read directory "/usr/local/Cellar/retrofe/0.7.20/collections/Main/roms". Ignore if this is a menu.

Perhaps that's an empty folder in need a of file or dot file?

I also recall messages about missing layout.xml inside of collections/layout. Would a layout folder be inside collections? I wasn't able to reproduce that so it might have been a fluke of an older build. Unsure. 

I just pushed out the RetroFE MacOS build to my fork!

I noticed that you recently added new changes to yours. I guess I have to sync what's changed between the two builds? I'm new to bitbucket so any tips would be appreciated before I issue a PR.

Notes:
* I updated the README.md. Linking URLs outside seems broken, leaving out quotes makes links internal.
* The RetroFE brew formula isn't live. So brew install won't be active yet.
* I assigned 0.7.20 in the Version.cpp. Is this about right?
* I patched png files with pngcrush (see readme)
* I used the icon from fan art.

I found a bug in RetroFE that I also confirmed with emp.
RetroFE will crash during the routine exit / quit if a Dualshock 3 controller is still mounted via usb or with bluetooth. I don't know if this will happen with other controllers but it's easy to test.

I made some good headway on the MacOS build!

RetroFE can be installed with Homebrew, keeping it simple!
RetroFE can be started from the command line 'retrofe' or as a clickable RetroFE.app!

Now a couple of things.
1) Do we have an official Icon I can use?
2) When starting RetroFE as an App Mac OS doesn't honor user defined environment variables that were set from the console. The GUI location of setting this up varies on which version of Mac OS X you are running. One way I can work around this is to allow the creation of a user made ~/.retrofe flat file. Inside that is a one liner '/your/new/retrofe-home'. At the moment this is a Mac only feature. If you think this would be useful for Linux too let me know. If so we should decide that when ~/.retrofe is detected does it supersede if $RETROFE_PATH was also set?