Poll: Did you try Qt5 on N900?
Poll Options
Did you try Qt5 on N900?

Reply
Thread Tools
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#141
If I was to build this for debian, can I just build the maemo module or would I need modified qt5-base as well?
 

The Following User Says Thank You to Android_808 For This Useful Post:
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#142
I just saw this on the Qt Devel mailing list:
Removing maemo/meego code?

Does the N900 Qt 5 effort use any of that code in question ?
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 4 Users Say Thank You to MartinK For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#143
MIght be worth posting that we do plan to use it.
 

The Following 2 Users Say Thank You to Android_808 For This Useful Post:
nokiabot's Avatar
Posts: 1,974 | Thanked: 1,834 times | Joined on Mar 2013 @ india
#144
Isint considrable effort being put in neo900 also support maemo then we should try to keep it in place
 

The Following 3 Users Say Thank You to nokiabot For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#145
i suppose a lot depends on how much specific code is still in the main code base. our version already has style qtmaemo5 module as a seperate, just like x11extras.

I'm currently looking at whether i can build a slightly modified qtmaemo module against qt5 shipped by debian in a jessie image (i'm all for using upstream as much as possible), or if i'm going to have to look at creating a new base package as well.

edit: on a side note, there is an issue with one of the repos. qtmaemo5-maemo-qt.. whatever the one is with the seperate qtmaemo5 module. it doesn't display any content via website or checkout correctly using git for me (problem with head not accessible, can't remember exactly at the moment). only way i could view content was locating an actual file in repo via google and then using that to access repo listing to download a zip snapshot

Last edited by Android_808; 2014-07-30 at 22:24.
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#146
I've posted to code-review page, which despite giving name still posted as anonymous

From what I can see, our version uses some of the files affected. It seems we add extra information to mkspecs for example, where as patch wants to remove completely. The total number of changes caused by the suggested patch isn't too huge so just need to see what happens and decide where we go from here.
 

The Following 5 Users Say Thank You to Android_808 For This Useful Post:
Posts: 567 | Thanked: 2,965 times | Joined on Oct 2009
#147
I am not a QT or X11 guy but from looking at the patch it seems like the primary purpose of those maemo changes in QT5 (the ones the patch wants to get rid of) is to implement support for various Maemo-specific wierdness to do with input. Possibly the answer going forward is to change the rest of the system so it is no longer non-standard and will work out of the box with the standard QT5 system.
 

The Following 3 Users Say Thank You to jonwil For This Useful Post:
Posts: 114 | Thanked: 298 times | Joined on Jan 2011 @ Berlin
#148
Well, in fact most of the changes are only relevant to Meego/Harmattan. I don't think we should ask the upstream repo maintainers to keep the code, for the following reasons:
  • It's not hard to readd it, once our fork is rock solid and has a clear future.
  • We can easily keep the parts we need in our repo
  • A small group should not keep a large project from tidying up
  • We should think of getting rid of the reasons for the adaptations in the long run.

@Android_808: IIRC you need to export additional symbols (see https://qt.gitorious.org/qt/qt5-maem...353321acfbdac8 and look for Q_WIDGETS_EXPORT) from qtbase in order to build qtmaemo5 and x11extras needs to be present, too. Furthermore the module depends on some Maemo specific stuff, so building it on a pure Debian might not work without heavy changes. That's because it mainly "qtresizes" the maemo5 gtk-style (using it, not resembling it).
So in the end one might need to rewrite it from scratch, maybe based on a theme that does not use gtk at all and is based on the hildon-components instead.

I'm sorry that I have so few time now (and that I didn't noticed recent posts). If anyone wants to push to the git repo just ask.

Last edited by frafI; 2014-08-02 at 15:49.
 

The Following 4 Users Say Thank You to frafI For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#149
I'm hoping to either tie it in to an updated qildon port so I can completely ditch gtk or base it on the gtk3 hildon port. The purer the qt library the better as it means less to track & maintain from our side. I'd like to get rid of the Maemo-specific wierdness as jonwill put it.

I did go quickly over most of the changes. Particularly like qt-declaratives as there's hardly any! I know there is a high likelyhood that I won't be able to use stock Debian lib, even if just for optification alone.

Haven't even got around to looking at what works or not yet. As an external module it is having a fit regarding headers. It doesn't seem to like not having an include folder and wants me to change #include <bla> to "bla" and vice versa. At the moment there the opposite way to in x11extras which does build for me. Simple fix but severly lacking in motivation this week. On a plus note, adding the extra directory I can also add files for <QMaemo5InformationBox> etc. in the process.

Did you see my post about HEAD: problem https://gitorious.org/qt5-maemo5/qt5...5/source/HEAD:
 

The Following User Says Thank You to Android_808 For This Useful Post:
Posts: 114 | Thanked: 298 times | Joined on Jan 2011 @ Berlin
#150
Maybe I have time to fix this during the next few days, but I'll be on holiday, so no guarantee.
If you want to completely get rid of the weirdness (which is good btw), you have to ditch the entire module because it is pure "weirdness". Future Applications will not need this because we can implement better UIs in QML with a lot less effort (also UI that look like hildon). Of course replacing Qt4 completely with Qt5 will require such a module.

Could you explain your plan in greater detail? Basically, you want to rebase a Maemo like distribution on the upcoming debian and all future apps should use mostly Qt5? What is the degree of compatibility, you're aiming at?
 

The Following User Says Thank You to frafI For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 15:38.