Open Source Front End - Design Docs

[Lilwolf]

As a list of all the 'features' that we would like added.  This is development independent.  These are MUST haves core hooks... or modules that you would like to add add (to make sure there would be a way to do it).

These are what I would like to see.

1) Moduler.  Ability for others to add functionality.
2) Model/View architecture.  
3) Standard config files.  No matter waht modules you have installed.  

[Lilwolf]

Some of the modules I would like to see

Different views...
 graphic - I want to work on a 3d one.  I'm sure we could get a ton of them.
 
 parsing - we should make sure that we allow easy hooks to be parsed for new emualtors.  It would also be nice if the parsers would keep track of the date of the .exe file and the number of roms of the last parse and automatically reparse every startup when these change.

 Storage - we should allow for xml or databases.  Databases really have a lot of advantages for weird searches... but most people wont want to deal with them.

 config... I would like to see it in ini text files myself.  Why?  easy to change by hande.  But I would love to see someone work on a view to change them.



The core needs to keep track of all emulators loaded, games.  The current one you are looking at.... to be able to get a new sorted list from the xml or database view.  Also all the configs.

Anything else?

[SirPoonga]

Some of the modules I would like to see

Different views...
 graphic - I want to work on a 3d one.  I'm sure we could get a ton of them.

I've been playing around with OpenGL lately.  There are some cool new stuff in OGL since I last used it.
www.gametutorials.com

I've been thinking of making a 3D FE for my future cocktail.  it;s wouldn;t be like )p( where you walk around in an arcade (col idea though).  It'd just be a 3D interface.  I;d like to use coktail models though in it.

 parsing - we should make sure that we allow easy hooks to be parsed for new emualtors.  It would also be nice if the parsers would keep track of the date of the .exe file and the number of roms of the last parse and automatically reparse every startup when these change.

 Storage - we should allow for xml or databases.  Databases really have a lot of advantages for weird searches... but most people wont want to deal with them.

that all kinda goes together, you need to store the parse info.  xml is perfect for that.  Though, you are right, SQL and DB give you fast search and can handle complex stuff quickly.  It;s why it is in my FE:)

[qoute]
 config... I would like to see it in ini text files myself.  Why?  easy to change by hande.  But I would love to see someone work on a view to change them.

true, but it shouldn't be overly complicated.  actually, my FE only has a few lines in the text file.  Though I am geared towards just mame, I grab roms dirs form the mame.ini.



btw, a dat file, at least for mame, is pretty much mame -listinfo

[Howard_Casto]

If you guys are serious about this, the hierarchy of lazarus already incorporates almsot all of these functions.  You could use it as a guide.  

[SirPoonga]

If you guys are serious about this, the hierarchy of lazarus already incorporates almsot all of these functions.  You could use it as a guide.  

Yes, it does.  I knew you where going to chime in eventually.

It needs to go a step further.  Combining the datfiles and catver and anything else into a master list, which you do.  (for me it is a master table in my my db).  
We'd end up with something like your master.lst.  Now, that's all cool, but to be made easier to work with so any FE dev can use the data, I propose the data bestored in XML.  Either in M$ or java or whatever, the xml doc gets loaded into an XML object.  You use a XML translator to get at the data you need.  XMl does all the hard work of finding and parsing the data for you.

An interface to all of this would then have to be made.

[)p(]

If you guys are serious about this, the hierarchy of lazarus already incorporates almsot all of these functions.  You could use it as a guide.  

Yes, it does.  I knew you where going to chime in eventually.

It needs to go a step further.  Combining the datfiles and catver and anything else into a master list, which you do.  (for me it is a master table in my my db).  
We'd end up with something like your master.lst.  Now, that's all cool, but to be made easier to work with so any FE dev can use the data, I propose the data bestored in XML.  Either in M$ or java or whatever, the xml doc gets loaded into an XML object.  You use a XML translator to get at the data you need.  XMl does all the hard work of finding and parsing the data for you.

An interface to all of this would then have to be made.

For a new project that is really cool...I like xml ;-)
(of topic: I have been thinking about it some more and for me personally I only have use for a dat file standardization...Howards (master)lists are enough for me with a little conversion, and that is allready in there, thanks Howard ;-) )

Peter

[Lilwolf]

What I really see is something that is mostly moduler.  All but in the configuration.

why?

If someone comes out with a new frontend, and I want to try it, I don't want to have to reconfig my emulators, my storage ect.

But I also want so we can store information in XML by default, but if someone wants a speed increase, they can load up the database, it would reparse everything and go.

[SirPoonga]

What I really see is something that is mostly moduler.  All but in the configuration.

why?

If someone comes out with a new frontend, and I want to try it, I don't want to have to reconfig my emulators, my storage ect.

But I also want so we can store information in XML by default, but if someone wants a speed increase, they can load up the database, it would reparse everything and go.

Yeah, like I was saying before.  There would be class, code, libraries, whatever that a FE developer can add to his/her project to use the data.   As long as the FE used those libraries, you could plug and play FEs.

XML is fast.  You aren't constantly parsing a file.  What you do is load the xml file into an XML object in memory.   The advantage a DB would have is the data is sotred in file and not in memory, but otherwise it would be fast.

[Lilwolf]

If I used a database, I could load the whole thing every time.

The advantages is that I could say give me all games in this order, and this filter.  Take them all in a single list and run the frontend with that.

The trouble with XML will be that you will want a full list of all the games in memory... then you will need to sort them and filter themself...

[SirPoonga]

The trouble with XML will be that you will want a full list of all the games in memory... then you will need to sort them and filter themself...

That's what an XSLT is for.  Go to your locallibrary, get XML books.  I suggest getting "XML for the world wide web" by elizabeth castro.  Granted it is for web pages, you get a very good idea on what and how to use a translator.  MS XML 4.0 has a decent translator.

[Howard_Casto]

Yeah... I'm with >p< in that personally I only need text from a masterlist.  BUT xml would be the way to go.  It's best because if you like to self-filter via your own code.  (Like me.)  You can simply read it in but as sirp said there are several ways to automate filters for xml. (my advanced html classes were two years ago so i can't remember any specifically, we just went over it)   I use an ini api from m$ to grab data quckly from configuration files.  The only catch with it is you have to have it in "variablename=variable" format under some kind of header like "[arcade]"  and each variablename has to be unique to do it without confusion. I don't know about macs but I've seen linux config files like this so I think there is a way to read this format of purely textual data  on that os at least.  Just something to think about purely on the configuration end.  

[SirPoonga]

Yeah... I'm with >p< in that personally I only need text from a masterlist.  BUT xml would be the way to go.  It's best because if you like to self-filter via your own code.  (Like me.)  You can simply read it in but as sirp said there are several ways to automate filters for xml. (my advanced html classes were two years ago so i can't remember any specifically, we just went over it)  

Actually, 2 years ago XML used DTDs, W3C didn't like that, they made an even better way to use XML with XSTL.

But HC is right, if you can't quite get the data you need you can make a function to do it for you.  XML objects are recursive tree objects.  That means and XML object can contain XML objects.  At least getting at the data is easy, you don't have to writ e a tool to parse the textfile, which makes it much easier and faster to work with.

Otherwise, I have, esomewhere, written in perl a textfile database handler.  I used perl alot in college.  I got sick of storing info in textfiles and manually figuring out how to make and get the data.  So I made perl module to abstact using a textfile db wher the field were seperated by | (like HC's lists).  Wouldn;t be hard to port something like that to any language.

I use an ini api from m$ to grab data quckly from configuration files.  The only catch with it is you have to have it in "variablename=variable" format under some kind of header like "[arcade]"  and each variablename has to be unique to do it without confusion. I don't know about macs but I've seen linux config files like this so I think there is a way to read this format of purely textual data  on that os at least.  Just something to think about purely on the configuration end.  

If not, it isn't hard to make a procedure to do that:)


OFF TOPIC:  AHHHHHHHHH, a Buffy video game.  The commercial sucks too....

[Howard_Casto]

How about this then... the latest version of my parser can parse out any of the listinfo data quite easily.  I only have some of them commented out because they are useless to my fe. I left them in because I noticed >p< uses them and I thought they might come in handy later down the line.  Anyway... based on some tests I've ran, the speed factor in parsing the listinfo is more dependant upon actually finding the data's position.  Once you extract all of the data for each game and put it in delimeted format you can rearrange, reformat or convert the data almost instantly.  When testing for the upcoming "merger" of 3darcade and lazarus  found I could convert my huge nasty master list with 10+ emus included pretty much instantly.  

If I made the source available could this parser not be used for other fe's and the source be used to make a similar parser for linux ect?  There's no fancy api's in this one, it's just pure logic and a few simple vb functions which could be replaced with regular code.  

After you get the delimeted text files, you could input them into a database or an xml page or anything farily easily.  I also use the descripton as my first field and sort them prior to generation so lil wouldn't have to worry about that if he read them in carefully.