Do you have a case study comparing the benefits/disadvantages of TKinter/Qt/GTK? Why exactly is "reducing dependencies" the most important factor? How about code cleanliness (I personally much prefer the signal-slot architecture over TKinter), or widget library (TKinter really misses any kind of "advanced" widgets to my knowledge).

Also, why are "dependencies" a problem here? I could see an argument here, if we were talking binary executables, and bundling, but this is not the case at all here...

yeah, this program is pretty small, we don't really need a lot of features that Qt offers.
we're anyway switching to Python-3 in this project, Tkinter has included in the package already and it's also easy to use and implement.
talking about code cleanliness, using OOP the code is clean enough to work with.

and why not bundle the project and to install it as dnf/yum package and use this instead of fedora easy karma, that would make the whole bodhi platform easier to use.

I'm not sure what you mean by

why not bundle the project and to install it as dnf/yum package`

and how that has anything to do with which GUI framework you use.

Maybe there is a misunderstanding, so let me be more clear - why exactly is getting less dependencies a win, and why is it the only (given so far) criteria for selecting TK instead of Qt or GTK? Dependencies are a non-issue, in Fedora, since you
1. can easily just specify dependencies in specfile, and one line more or less in Requires really does not make the difference
2. can not bundle libraries anyway

If the only reason for selecting TKinter is "it is bundled in python", then I don't see it as an informed decision.

Do you have mockups of the GUI ready? Do you know what kinds of widgets you are going to need, and how each GUI framework stands? Have you made any kind of research or case study? DO you have a list of pros/cons for each? Tl;dr - how, and why did you choose TK over the others.

talking about code cleanliness, using OOP the code is clean enough to work with.

I can show you plenty of awful OOP code. OOP on it self does nothing for code cleanlines :D

I'm not sure what you mean by

why not bundle the project and to install it as dnf/yum package`

I think he means "let's package it into Fedora". Zubin, this project has already been packaged in the past, it because it got broken and nobody fixed it, we removed it from Fedora. If anyone fixes it again, we'll definitely want to have it in Fedora again.

Regarding the GUI framework to choose, I don't personally care as long as it does the job well. That said, there should be a good reason to throw away the current QT code we already have, because re-writing the GUI is a massive task. So for example if the current graphical libraries were obsoleted and there was no way to make it run on Linux again, that of course would be a good reason. Or if you know Tkinter and don't know QT and don't want to learn it, that's something to consider. Reducing dependencies doesn't sound as a good enough reason, because dependencies by themselves are not a problem.

As I said before, I believe that the first step, before choosing the GUI framework (especially when you want to use quite a limited one, as GTK/QT can do next to anything these days), should be a feasibility study - you should have mockups and workflows prepared, in order to determine "what you need". Might easily happen, that you'll get to a point where TK is not sufficient - showing html-formatted text is an easy pick here, as TK can't really do anything but the most basics, and some of the data you'll get for the gooey karma might as well be html pages, that you'll be forced to re-format into something else then (can easily happen with embedding RHBZ information for example).

On the toolkit issue, also worth noting that both Workstation and KDE - our two main desktops - include Qt by policy. Nothing, AFAIK, can be relied on to include Tk. So using Tk effectively adds more dependencies when deploying on the most typical Fedora installs.

Well, I believe that the selection of GUI toolkit does not really matter.
If somebody wants to start developing the tool, they will choose whatever
suits them best. We can talk about different toolkits for days, but if
nobody really sits down and starts typing, we will never have anything
anytime.
Zubin, do you want to start working on the tool and you only seek approval
to use Tkinter? I personally like Tkinter, because it is easy to use, but
it is true that the looks of the widgets is a little to old fashioned.
Have a nice time.

@kparal @lruzicka I side with both of you, I personally feel that since the GSoC gives the students 2 months time to code and get things to work. It's hard if we fixate on a specific choice but again @adamwill's idea of using a specific toolkit since it's shipped with two of fedora's main desktops make sense and so does @jskladan's points.
I say that @imzubin to make a call on how much familiar he is with TK and if it will be a problem to get it Qt.
It's worth noting that Tk is very easy to use and in coming years we might want to have some contributor to easily understand and maintain it.

For all, Zubin is working on a layout/wireframe for the Gooye karma which he will update here as well.

@all - I just feel the need to clarify, that I honestly could not care less what GUI toolkit gets used. It's just that "less dependencies" does not warrant that choice. "I don't know QT/GTK, but am familiar with TK", or "From what I learned [links to sources] TK is easier than GTK/QT to use/learn. It also meets all the (projected) needs [list of identified requirements] of the GUI, so I'll go with that" are.

That's not the reasoning given by @imzubin, though, hence the questions aimed at the reason given in the OP. IMO analysis and research are a crucial part of any project, more so when it's a "learning experience", especially GSoC.

I'm more than open to discussing any other reasoning, I just find the "deps are bad" argument to be invalid.

I also agree with @lruzicka that it can be more efficient to "just start, and see", but not on such a constrained timeframe (as @sumantrom pointed out), when the time given to learning "something" that fits from the start is better spent, than rewriting the code from scratch when the proverbial roadblock caused by an ill choice comes. For a pet project, I'd be all for the "better do something than nothing" approach, but once again, I do not believe that GSoC warrants such attitude.

Also, from my personal experience, all TK, GTK and Qt are simple to learn/start with, especially if you limit yourself to the set of features given by TK. GTK/Qt can be harder, because these can (or can seem to) offer more choice, but architecturally, they are all (IMO) on the same level of "difficulty".

The other benefit I see in QT/GTK are the "builders" (glade/qt creator) which can do a lot. Not that there are not any for TK, but I found them lacking (at the time, I understand this might have changed in the past five years, even though I'd be quite surprised if it did).

Anyway, do whatever, just be prepared to explain the choice made :) Thanks!

read through all the comments and had a word with @sumantrom , decided to go with Qt.

This was not fixed (implemented), adjusting close status.