Please add some features!

I ran your code @seandye13, and everything seems to be as it should be. The colors look good, and I can't wait for the flashcards to work. When I click on your card, it just closes the program. I don't know if it's supposed to do that or if you're still working on it. I would maybe change the name of your class since having a class named Graphics and using the graphics package could potentially create problems in the future. Other than that, great job on the graphics portion! I can't wait to see your app when it's done!

Your code seems pretty good so far @VictorPerez07032000, but there are a couple things that could be tweaked. In your code you call on a deck function that hasn't been created yet. I'm sure you're still working on the code, but this was just something I noticed. Also, I tried running your code but nothing came up. Try tweaking the code a little so we can see how it works so we can give you better feedback. Other than that, I didn't see any other problems.

A deck object will be a collection of flash cards.

This code is your start for the text interface, right @VictorPerez07032000? A few recommendations based on what is present here:

1. You will want to coordinate with @seandye13 and @Ecret on the nomenclature for all the interacting pieces. For example, just like in our Dice Poker app, we had to be aware of the names of all classes and their respective methods and properties before coding. You should coordinate with @seandye13 to make sure that your TextInterface and GraphicsInterface have the same properties and methods, so you can using them interchangeably with your FlashApp program that runs the entire app.

2. Speaking of which, make sure that you are designing your app according to the model-based approach. The app that runs that program should run the main program, not the interface class as is currently done in @seandye13's interface object, and in the play method of @VictorPerez07032000's object. From an input-output perspective, the Interface object gets inputs from the user that are fed into the app. In this way, we aren't thinking about the graphics of the app as integral to the app itself: they are only a way of getting inputs from the user, and passing outputs back to the user.

3. The current code doesn't have a way to test run it. Consider adding something like:

if __name__ == '__main__':
    interface = Interface()
    interface.drawCard()

4. Your current code has some dependencies that don't exist yet. I see that your __init__ function calls on a Deck class that doesn't exist yet. Be careful here-- your interface shouldn't be creating new decks from scatch; it should get a Deck as input from the main App. That way the main can control which decks are displayed, rather than hard-coding them into your program. For example:

__init__(self, deck):
    self.deck = deck

This will be the basic unit for the flash card app.

I was looking over the code you have made currently for the graphics interface for your program @seandye13 . Your code currently runs (kudos!). Here are a few pointers I would recommend:

1. Change the name of your file and class. As you are divvying up the package into components that work with each other, you should have a file dedicated entirely to functions and classes that deal with the graphics interface. A filename such as interface.py may be more appropriate. I am also concerned that your class name Graphics may get confusing, as you are using a graphics package called graphics.py and they do separate things. They currently don't interfere with each other, because of the difference in capitalization.

2. You mentioned that you hard-coded in the text to be displayed on the card. Eventually, you will want to read in this information from the Card class that I believe is being developed by @Ecret? The Card class should have no graphical components, but should handle all the information about the card e.g. front/back of the card. I think it would make most sense to do this in a single function, rather than separating them into card and text methods.

3. Building on (2), consider making all your methods verbs. So I think a better method would be drawCard to indicating that you are creating a card on the screen.

4. Your run method is eventually going to need to be more complicated. It will need to have a starting interface, a button to allow you to load current decks, create a new deck, and close.

5. You will want to create additional classes for additional windows e.g. StartingWin for the launch screen and ReviewDeckWin for reviewing an existing deck.

This would be to add a card to an existing deck.

To make sure flash card and deck objects work

It might be too much to add a right/wrong answer grading for the cards, but I think we can at least add a counter for the # of times decks have been completed to show the user how many times they have studied that deck and give a good job graphic at the end?

counts every time game is completed on a particular deck

This is the window taken to after user chooses to use an existing deck from the starting window.
This window should show buttons for different decks that have already been saved by the user.

Save this in the README filee.

This window would start the game for user to go through each card in a randomized deck of cards.

Was thinking for this window, would draw question, then undraw that and draw answer. If that's too much for each card, maybe just a window for every question/answer?