qreator-discuss team mailing list archive
-
qreator-discuss team
-
Mailing list archive
-
Message #00031
Re: QT vs Gtk
Al 30/11/12 11:26, En/na Stefan Schwarzburg ha escrit:
> Hi David,
>
> thank you for your answer!
> I will not go into details again, but I think that in general we agree :-)
>
Cool :)
> I have started the comparison table in the wiki, but you might know more
> about i18n and localization.
>
I saw that, thank you so much for doing the research and filling the
table in. That's exactly what I had in mind and more!
Regarding i18n/l10n, I think we can get away with just having one row
for i18n (that is, if the toolkit has got good internationalization
support, we can assume it can be well localized).
I think except HTML5, all toolkits should support i18n. I've been
looking at kivy a bit, and if I understand it correctly, it's 100%
Python code and should support gettext as usual. The only part that I'm
not too clear on is whether the _() gettext call can be used in Kv, but
having asked on #kivy, they tell me that Kv files can contain Python
imports (e.g. #:from gettext import gettext as _) and Python calls (e.g.
_('translate me!')), so if that works out, then i18n is implicitly
supported.
> My take on this is issue at the moment is, that I do not like Qt, but
> I'm happy to learn it, so that this feeling will then either be based on
> in-depth knowledge or dissapear...
>
That's the spirit :)
> I think that I will use kivy for other projects.
>
Yeah, Kivy looks really cool and nice to program with, especially with
its more pythonic interface. I'm still more inclined to use Qt, but as
you said, let's focus on separating logic and UI for now.
Btw, regarding the Python 3 port, you'll be glad to hear that it's
happening: "Kivy got a $5000 grant from the Python Software Foundation
for porting it to Python 3.3" -
https://groups.google.com/forum/#!topic/kivy-users/5Z_UJOoBeIc/discussion :-)
> Still, we have to plan in detail, which parts of the window will be qml
> based, and which will be qwidgets based.
>
I agree, I need to delve into Qt a bit more myself first.
Thanks!
Cheers,
David.
> Cheers,
> Stefan
>
> On Wed, Nov 28, 2012 at 4:46 PM, David Planella
> <david.planella@xxxxxxxxxx <mailto:david.planella@xxxxxxxxxx>> wrote:
>
> Al 24/11/12 17:04, En/na Stefan Schwarzburg ha escrit:
> > Hi David,
> >
> > today I spent some time waiting with a smartphone in my hand, and used
> > that time to research PySide and QML.
> >
>
> Hey Stefan,
>
> Thanks for your time looking into this. Let me try to reply inline.
>
> > I have to say, that I'm less than impressed. Actually, PySide seems to
> > be even more verbose and convoluted than PyGObject, and I already
> > thought that this was at the edge of being acceptable.
> >
>
> I can't reply on this one, as I haven't played with it much yet, but
> unless it's extremely convoluted to write the code, I'm not personally
> much concerned about it if the end result is going to be a significant
> improvement.
>
> > And QML, while a step in the right direction from the Glade ui
> files, is
> > very Javascript heavy. It seems as if designing is not really possible
> > without JavaScript.
>
> In my little experience with QML, my understanding is that:
>
> - You can design apps with QML alone
> - For more complex apps, you might need to add Javascript
> - For even more complex apps, you'll need to resort to C++ (or in our
> case, Python)
>
> But, of course, this will have to be put to the test to see if it really
> applies or I'm just talking nonsense :)
>
> > From the perspective of a C++ developer, QML is certainly a step
> in the
> > right direction. Developers and designers now have to write much less
> > C++ code, and I understand that this is a good thing. Now, GUI heavy
> > applications can be written with Qt, but completely without C++.
> > But from the perspective of a Python developer, JavaScript is not
> a step
> > in the right direction (at least not for me).
> >
>
> Right. To be clear, it's my intention to stay on Python too, and not go
> into the C++ or JavaScript realm. Now, if we have to write a small
> amount of JavaScript in addition, and for UI purposes only, I don't see
> it much of an issue. Assuming that our logic and core code is in Python.
>
> > I think that if we really set our minds to developing Qreator with
> > JavaScript, we should really use HTML5+CSS3. This would allow us to
> > completely ignore the desktop, be open for every OS, and let the
> > integration be done by Ubuntu-webapps or similar.
> > However, I don't like the idea of using JavaScript. Actually,
> since this
> > is a project that I like to do in my spare time, I would prefer to
> stick
> > to Python.
> >
>
> I agree with the point of going to HTML5, but not because of a potential
> switch to JavaScript. If we were to go to HTML5, the two main 'pro'
> points would be:
>
> - It is a web-wide standard
> - It would allow us to have the same code running on the web and on the
> desktop
>
> However, if we were to do that, I'd rather use the approach of embedding
> the UI into a webkit view and have the backend still be Python (with
> perhaps a small amount of JavaScript if CSS3 would not allow us to to
> everything we want to do). There is some example code in the Quickly
> HTML5 template at https://code.launchpad.net/quickly-community-templates
>
> Having said that, I don't think HTML5 is ready for our purposes yet, as
> I'm still primarily considering Qreator to be a client app, not a web
> app. The spanner(s) in the works for me are:
>
> - No native widgets
> - No Unity integration
> - No internationalization support
>
> > So my suggestion would be to focus (after that release) on the
> > separation of GUI and background-logic and then we can explore Qt,
> but I
> > would then also like to explore kivy. The kivy language is very much
> > like QML, but integrates python in stead of JavaScript, and kivy
> itself
> > is the most pythonic GUI-toolkit I have seen so far.
>
> I fully agree. However, although it looks pretty awesome, I'm still not
> convinced by kivy.
>
> For the purposes of exploring our choices, I've created
> https://wiki.ubuntu.com/Qreator/GetInvolved/Brainstorm/GuiToolkitChoice
>
> If you'd like to advocate for kivy, would you mind filling in the kivy
> part, so that when we make the actual decision we can base it on the
> facts from our research?
>
> Thanks.
>
> > I'm aware that kivy has many disadvantages, especially the lack of
> > support from Unity specific tools (dbus-menu, HUD, Gtk-themes,
> ...) but
> > I think that I will have much more fun coding with kivy than with Qt.
> >
>
> I think the fun factor is an important one to take into account,
> especially when contributing to a project in the spare time. However, we
> should also throw into the mix the end result for users,
> maintainability, documentation and other factors to come up with a good
> balance.
>
> If you've got any ideas for the criteria we should evaluate when
> choosing the GUI toolkit, please do feel free to add them to the wiki
> page, I've added a placeholder text under the comparison table header.
>
> Thanks again for your input!
>
> Cheers,
> David.
>
> > Let me know what you think...
> >
> > Cheers,
> > Stefan
> >
> > On Fri, Nov 23, 2012 at 5:01 PM, David Planella
> > <david.planella@xxxxxxxxxx <mailto:david.planella@xxxxxxxxxx>
> <mailto:david.planella@xxxxxxxxxx
> <mailto:david.planella@xxxxxxxxxx>>> wrote:
> >
> > Al 23/11/12 16:27, En/na Stefan Schwarzburg ha escrit:
> > > Hi David,
> > >
> > > one small question: Your plan was to switch to Qt after this
> release,
> > > right? Not to develop two GUIs in parallel...
> > >
> >
> > Exactly, that was the idea, a switch and just one single UI.
> >
> > Cheers,
> > David.
> >
> >
> > --
> > Mailing list: https://launchpad.net/~qreator-discuss
> > Post to : qreator-discuss@xxxxxxxxxxxxxxxxxxx
> <mailto:qreator-discuss@xxxxxxxxxxxxxxxxxxx>
> > <mailto:qreator-discuss@xxxxxxxxxxxxxxxxxxx
> <mailto:qreator-discuss@xxxxxxxxxxxxxxxxxxx>>
> > Unsubscribe : https://launchpad.net/~qreator-discuss
> > More help : https://help.launchpad.net/ListHelp
> >
>
>
>
>
--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References