Merge lp:~thisfred/u1db/u1todo-2 into lp:u1db
| Status: | Merged |
|---|---|
| Approved by: | Eric Casteleijn on 2012-04-23 |
| Approved revision: | 253 |
| Merged at revision: | 252 |
| Proposed branch: | lp:~thisfred/u1db/u1todo-2 |
| Merge into: | lp:u1db |
| Diff against target: |
330 lines (+219/-4) 4 files modified
u1todo/test_u1todo.py (+35/-2) u1todo/u1todo.py (+32/-2) u1todo/u1todo.ui (+58/-0) u1todo/ui.py (+94/-0) |
| To merge this branch: | bzr merge lp:~thisfred/u1db/u1todo-2 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Roberto Alsina (community) | 2012-04-19 | Approve on 2012-04-23 | |
|
Review via email:
|
|||
Commit Message
Initial UI: adding editing and deleting tasks works. Done status and tags not so much.
Description of the Change
Initial UI: adding editing and deleting tasks works. Done status and tags not so much.
to test, run:
PYTHONPATH=. python u1todo/ui.py
from the checkout root.
| Lucio Torre (lucio.torre) wrote : | # |
| Lucio Torre (lucio.torre) wrote : | # |
i know its a bit premature, but i would get some time from the people from design to get a very minimal but useful UX for the todo list. :)
| Eric Casteleijn (thisfred) wrote : | # |
> 173 +class UIMainWindow(
> 174 + def setupUi(self, MainWindow):
>
> This function scares me a bit. I dont know the desktop+ prefences about it,
> but i was expecting some declarative thing taking care of that. Is that
> reasonable?
I don't really know: I used QtDesigner to get off the ground, and that is what it generated. Maybe I should put it back in a separate module so that nobody thinks of it as part of the example code. ;)
| Roberto Alsina (ralsina) wrote : | # |
> > 173 +class UIMainWindow(
> > 174 + def setupUi(self, MainWindow):
> >
> > This function scares me a bit. I dont know the desktop+ prefences about it,
> > but i was expecting some declarative thing taking care of that. Is that
> > reasonable?
>
> I don't really know: I used QtDesigner to get off the ground, and that is what
> it generated. Maybe I should put it back in a separate module so that nobody
> thinks of it as part of the example code. ;)
Talk to me when I start working and I'll show you the problem with that :-)
| Roberto Alsina (ralsina) wrote : | # |
> > 173 +class UIMainWindow(
> > 174 + def setupUi(self, MainWindow):
> >
> > This function scares me a bit. I dont know the desktop+ prefences about it,
> > but i was expecting some declarative thing taking care of that. Is that
> > reasonable?
>
> I don't really know: I used QtDesigner to get off the ground, and that is what
> it generated. Maybe I should put it back in a separate module so that nobody
> thinks of it as part of the example code. ;)
Oh, well, should not look at code before waking up, I guess. Lucio, that's generated code.
| Lucio Torre (lucio.torre) wrote : | # |
That does not make it better.
The project has the generated code and no ui file, and the code already includes some functions which were not generated.
I would really prefer to read some static definition in runtime that we can also open back with qtdesigner.
| John A Meinel (jameinel) wrote : | # |
On 4/20/2012 1:23 PM, Roberto Alsina wrote:
>>> 173 +class UIMainWindow(
>>> 174 + def setupUi(self, MainWindow):
>>>
>>> This function scares me a bit. I dont know the desktop+ prefences about it,
>>> but i was expecting some declarative thing taking care of that. Is that
>>> reasonable?
>>
>> I don't really know: I used QtDesigner to get off the ground, and that is what
>> it generated. Maybe I should put it back in a separate module so that nobody
>> thinks of it as part of the example code. ;)
>
> Oh, well, should not look at code before waking up, I guess. Lucio, that's generated code.
Note that usually there are 2 ways to deal with QtDesigner. One is that
you create an XML (.ui) file that has the widget layout, which then gets
loaded by the Qt runtime and has objects instantiated.
The other is that it generates python/c++/$lang code directly rather
than a .ui file, and that essentially has the same code as would have
been run when loading the .ui file.
The difficulty in both is how you attach your own functionality to it. I
believe with the .ui file you have to have a proxy object, while with
the .py file you subclass it and add methods to your subclass, and just
regenerate the super class using QtDesigner from time to time.
John
=:->
| John A Meinel (jameinel) wrote : | # |
On 4/20/2012 1:40 PM, Lucio Torre wrote:
> That does not make it better.
> The project has the generated code and no ui file, and the code already includes some functions which were not generated.
> I would really prefer to read some static definition in runtime that we can also open back with qtdesigner.
>
>
I haven't looked at the code, but yes, if a given file is generated, it
should not be modified in place. Instead a separate file should inherit
from that one to provide the custom functionality.
John
=:->
- 251. By Eric Casteleijn on 2012-04-20
-
dynamically load the ui.
| Roberto Alsina (ralsina) wrote : | # |
Eric, we should make the code follow the standards we have for the rest of Desktop team's projects. I amnot going to suggest pylint, but try to make pyflakes and pep8 do a clean run on the code, please.
Other than that, it looks pretty good now, there are some missing docstrings though ;-)
- 252. By Eric Casteleijn on 2012-04-20
-
added docstrings
- 253. By Eric Casteleijn on 2012-04-23
-
moar docstrings
- 254. By Eric Casteleijn on 2012-04-23
-
remerged trunk

173 +class UIMainWindow( object) :
174 + def setupUi(self, MainWindow):
This function scares me a bit. I dont know the desktop+ prefences about it, but i was expecting some declarative thing taking care of that. Is that reasonable?