appyface Posted February 24, 2009 Report Share Posted February 24, 2009 Using version 1.0.3... 1. Could we have a display of the full path and filename of the opened database? Title bar, status bar, or some other place in the Ketarin GUI? 2. Could Ketarin store and use all the user-specific settings, via an INI or other config file? Or be able to export these settings to INI or config file, and reload them upon request? I can export my apps to XML and reload them to brand new database, but all the other settings such as the new add-app defaults (thank you!), global variable for custom column, global variables, global commands, downloading threads, etc. from global settings dialog, must all be setup again by hand? Would be nice to reload these, too. Thanks in advance for considering these for the wishlist! --appyface Link to comment Share on other sites More sharing options...
floele Posted February 24, 2009 Report Share Posted February 24, 2009 1. I won't introduce a statusbar for that. Nor do I want to "spam" the title bar. 2. Nope, we'll stick to the jobs.db. Exporting settings might be possible, but that's exactly top priority currently. Link to comment Share on other sites More sharing options...
CybTekSol Posted February 24, 2009 Report Share Posted February 24, 2009 Could Ketarin store and use all the user-specific settings, via an INI or other config file? Or be able to export these settings to INI or config file, and reload them upon request?I must agree that this would be useful for me as I have started installing Ketarin on everything in sight lately! Would simplify the process, in the interim, I have created a new Jobs.db with the default settings and simply copy it to the new machine. Link to comment Share on other sites More sharing options...
appyface Posted February 24, 2009 Author Report Share Posted February 24, 2009 Awww Flo, you considered showing the path to the *.db previously for me: http://ketarin.canneverbe.com/forum/viewtopic.php?pid=1331#p1331 I can of course add an info to the about screen about the database path. The 'about' screen would be fine... I'm just after some way I can see from within the Ketarin GUI, just what db I've got open...? RE: Other settings. There are a couple of really good uses for an export/import of these other settings than what is in the app XML: 1. As soon as there is a new feature (example: 1.0.3 with the new user defaults for new apps), I can fix up one db, export my settings, and import them to all my other existing db's (assuming I want them all configured the same; I do) 2. While I can and do tote an empty *.db around that has my settings pre-configured, I really like the idea that I can have Ketarin create a completely empty db, and I can import everything into it. Right now that is just the apps, but for a true clean slate it is good to be able to import the other settings too instead of typing them all in again. It is possible this could be useful in the event of a database format change, where a clean start from a blank DB might be helpful for troubleshooting, or just to ensure there is no corruption lingering around from prior DB. Please reconsider for wish list? TIA, --appyface Link to comment Share on other sites More sharing options...
CybTekSol Posted February 24, 2009 Report Share Posted February 24, 2009 The 'about' screen would be fine...It has already been implemented... I believe for the last few beta releases. Link to comment Share on other sites More sharing options...
CybTekSol Posted February 24, 2009 Report Share Posted February 24, 2009 Please reconsider for wish list?Flo... you can count me in on this also... the export/import settings feature that is... I don't care how it is implemented but it would help. Link to comment Share on other sites More sharing options...
appyface Posted February 24, 2009 Author Report Share Posted February 24, 2009 The 'about' screen would be fine...It has already been implemented... I believe for the last few beta releases. It IS????? Dang!!! I didn't even look!!!! Thanks!!!! Link to comment Share on other sites More sharing options...
floele Posted February 25, 2009 Report Share Posted February 25, 2009 It is possible this could be useful in the event of a database format change, where a clean start from a blank DB might be helpful for troubleshooting, or just to ensure there is no corruption lingering around from prior DB. You shouldn't do that. If there are errors resulting from an upgrade, the upgrade procedure needs to be fixed, not your database. Link to comment Share on other sites More sharing options...
appyface Posted February 25, 2009 Author Report Share Posted February 25, 2009 I agree, if upgrade causes errors program should be fixed. Absolutely! I still think my ideas have merit though Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now