![]() |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Just a slight update, so everyone knows what's going on: I got a little sidetracked (understatement of the century...) by the arrival of my N900 today.
I've still started on the summary, and will send it tomorrow morning, lunchtime at the latest. I'll link you all to the archive thread so those not subscribed can follow there, but I'd strongly suggest that anyone interested subscribe also, as it could prove an interesting discussion. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Assuming that DUI *is* Symbian as well (I've seen no mention of this, but granted, I don't follow Symbian development closely), then this still leaves other platforms out in the cold, meaning it's not a part of the regular Qt API, meaning I can't write once, run anywhere - and can't develop and test with my regular PC with Qt Creator which is what I'm used to doing.
Even assuming DUI becomes mainstream, then, there becomes the point of asking why it exists *in the first place* instead of these additions being added back to the regular Qt API, because when you look at DUI, pretty much all of it is just subclassing and adding a small amount of stuff, much the same way Hildon wrapped GTK and did its own stuff. So, it's still an issue to me, and I personally am hoping I can find out more out of it starting tomorrow. Thanks for your feedback, ColonelKilkenny. :) |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Right - I come bearing news
I wrote up a summary of what I gathered to be the points here (portability, fragmentation, etc), and sent it on to qt-maemo-feedback. I've just received the first reply, linked for your interest here: http://lists.trolltech.com/pipermail...er/000045.html Summary of points: - I need to ask elsewhere about Dui (which I will do) - QMaemo5* classes *are not* intended to be too pervasive, but only where things cannot be covered by more generic concepts. - QMaemo5KineticScroller will stay, but it will not be needed unless fine-tuning of scroll behaviour is required Are there any other areas of direct concern with QMaemo5 I can bring up? |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
I'm glad to see you got a fast and clear technical answer directly from one of the developers of the Qt 4.6 port for Maemo.
Now about the dui libraries, before you ask in maemo-developers make sure you have already gone through http://www.slideshare.net/peterschne...6-ui-framework and the posts of Tomas Junnonen in this own thread. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Let's say the division gets to the point where it's not so fragmented but simply between desktop/laptop platforms vs highly mobile platforms (of any kind). Would that scenario be so bad?
Note that I am solely speculating here; no advance info of any kind in my head. :D |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
My main concern, really, is splintering for the sake of splintering. But like I said, I want to do some more reading first. Thanks for your reply! |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
Again, sheer speculation for sake of my understanding. EDIT: ah, maybe I misunderstood your response. Ok, I see the issue now... |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
I don't think windows mobile will have DUI support.
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Hi,
I'll start by saying I work for the Symbian Foundation but these are my own opinions, not those of my employer. I'll also add that I'm a big Maemo fan too - I've had an N800 for ages, and my N900 is sat at the local DHL office ready to be delivered tomorrow. :-) The criticism on this thread is spot on. Mameo DUI and Symbian DUI are not the same thing (as I understand it, the Symbian side of things accidentally stole the term from Maemo). I've investigated this myself (and I used to be a software architect at Nokia, so you might consider I have some idea what I'm talking about) and I've also talked to people whose opinions I respect in the Qt, Symbian and Maemo organisations. We all agree - this Direct UI madness is a big mistake Nokia is making and it's going to come back to bite them. To quote Tomas Junnonen from earlier in this thread: Quote:
The very concept that Maemo and Symbian (via Orbit - currently being renamed Symbian^4 UI framework) should build new UI frameworks on top of Qt, which is supposed to be a cross-platform application and UI framework should have set alarm bells off everywhere! When you consider that Qt is owned by Nokia, along with Maemo and almost all of the Symbian development teams - it seems almost inexcusable that there should be any framework built on top of Qt. However, given that there could be a desire to preseve the quality of Qt by not expanding the team working on it too fast or diluting the quality of the engineers, and at the same time a business need to build some products on top of the technology, you might be able to excuse a common set of widgets etc on top of Qt for mobile devices. Unfortunately two separate sets is just insane and WRONG, WRONG, WRONG! Of course there and plenty of smart people in Nokia and this was not the original plan. The thing called Orbit was meant to be cross-platform. I heard from a fairly senior guy who sat on strategy meetings that the teams involved were basically looking for reasons to diverge and build separate frameworks from day 1 - as soon as the strategy was laid out. Why? Well there were two teams building UI frameworks before Qt was acquired and a lot of people that would like to justify their jobs! Also, building a new UI framework on GraphicsView is interesting and challenging work which the engineers in both camps would love to do. Could they not have worked together on a single one? Apparently not. Quim Gil, who I generally have a lot of respect for, seems to be in defensive mode here: Quote:
There is absolutely no reason why you can't build completely different looking apps and platforms with the same application and UI framework. I realise that Nokia employees can't agree with me publicly and criticise the actions of their colleagues and the company they're working for. However, people with the influence of Quim Gil need to recognise the mistake that is being made and work to fix it before it's too late, or at least minimize the damage if it is indeed past the point of no return. Quote:
Waiting until these things have shipped will be too late. The Symbian one is not yet available for anyone outside Nokia to compare with what Maemo are building. By the time they do and all start ranting at once, it'll be too late for you to do anything about it and another own goal for Nokia. Developers will want to build different UIs for different form factors in the future, and Qt's technologies, particularly QML should make that feasible in terms of time and effort. However, make the fragmentation optional or at least only reflecting real physical differences like screen size and input capabilities - don't create it artificially along political boundaries within Nokia's organisation. Qt - cross-platform applicaitons for all Nokia devices. QGraphicsView - excellent technology for creating next generation UIs. Great strategy, botched implementation - PLEASE do everything you can to fix it. Mark |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Hi Mark, nice post with good technical insight.
Now, you know that software is developed by people with goals. In theory you can look at a toolkit and conclude that it will take this time for this amount of people to come up with a release. In practice this doesn't work like this. Remember how was life around Qt only 2 years ago. Trolltech was a company in Norway. Symbian was a closed core OS developed by a company in the UK. There was S60 developed in a closed environment by several companies. Maemo was a GTK+ based platform pushed by a small team living basically out of the Nokia mainstream software strategy. Now, at which point and at a which cost would you have been able to create the single team developing the toolkit to make everybody happy? Qt, Symbian and Maemo have different stakeholders with some overlaps. They have slightly different ways of working. The three organizations are going through huge transformations and in the meantime they have roadmaps, releases and products going out to the market. And yet they still have own goals, even if they complement each other and are sometimes common. And yet they are converging their interests and releases around Qt, taking care of their own goals and stakeholder while adding on top instead of forking or reinventing. The three organizations are committed to open source development and early pre-releases, and this is why you have the elements to start this discussion in the first place. This public exposure and this long road to stable releases will fine tune a lot of what can be improved together. I still believe this discussion will be more useful when we have concrete SDKs and platform releases to compare. The day someone comes pointing to duplicated, pointless or missing features then we will be able to have a proper technical discussion. In the meantime we must play this game where you are the apocalyptics and we are the integrated, when actually the picture is more interesting than that. Note that this multiparty exercise (that includes you) has a chance of big success precisely because the setting is more wide and diverse. This is one of the reasons why I think I'm working in the right platform and in the right direction, even if the story is not always as simple to explain as I'd wish. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
So the API has to be gotten right for Harmatten. No developer wants a third, yet again incompatible API for Harmatten+1. If we wait for SDKs to come out, it will be to late to change such fundamental things (at least for Harmatten). History proves this: the Fremantle SDK still ships with an ancient Python and a broken (!) gdb. Even the Maemo5 Qt team inside Nokia can't get the SDK team to ship an updated gdb that will work with Qt apps. The Symbian and Maemo teams have announced their plans for the future. If what Mark Wilcox writes is correct, we will have similar but incompatible APIs for Symbian and Harmatten. Now, why would I need a SDK to be able to talk about that? So I can check for myself that my Harmatten app just produces compile errors on S60? Obviously we need to talk about this right now and influence the proper people so that no SDK is ever released publicly with those incompatible APIs. In the alternative, a simple statement by a Nokia representative :) that of course API compatibility is a top priority and is being worked on as we speak will go a long way. Or am I missing something? |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Hi,
Thanks for the lengthy response. I don't see this situation as apocalyptic and I'm really glad that both platforms are in open source so we can start doing something about this rather than Nokia dumping a couple of largely incompatible SDKs on us shortly before products ship. Quote:
Quote:
Quote:
Yes, there were many market pressures and some people were probably in a panic but still I find that sad. However, it's crying over spilt milk now. I don't really care why we got here (except that Nokia should take this back for its lessons learned). What are we going to do about it? Yes, we can all get more fully involved in the conversation when some alpha SDKs are available. But the information we have already is enough to throw up red flags. I hope that you also take this back internally and get people to review things. However, there are specific things in this thread that I wouldn't want to see dismissed. For example QApplication works across so many platforms, and you can build and test code on any one of them. Why then must I build a DuiApplication? I'm not going to be at all surprised if the Symbian^4 UI framework does something similar. If there is platform specific initialisation to be done, why can't it be pushed into the private implementation of QApplication for each platform? Just because KDE does it too doesn't make it right. ;-) Oh, and don't worry, I'm only complaining at Maemo first because they've released their code first. I'll be giving the Symbian guys even more of a hard time when I get the chance. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
By SDK I also mean an environment where you can see that code in action, both providing the UI under discussion and the API to play with.
Discussion around source code only is possible but it requires similar levels of knowledge and abstraction to keep a fruitful discussion. Like now. Some people see the N900, see the N97 and conclude that there are no strong reasons to have different Maemo and Symbian optimizations on top of Qt. I bet things will be clearer when the first pre-releases come. Having SDKs out also allow people to see how plain Qt apps integrate in both platforms with the same source code, somethng that currently you have no other choice than imagining it yourselves. Remember the intense No Cancel Button discussion? Big deal, and yet nowadays everybody agrees it was a good decision. Ths is what I mean when I say that some discussions need something tangible to base the debate. We are discussing UI code here without having seen any actual UI. What would be interesting feedback now would be features, widgets etc that you are missing in Qt 4.6. Specially interesting if they happen to be expected by, say, iPhone or Android developers. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
For some time already I wanted to join this discussion in a productive manner. But as this is quite a complex subject I was unsure where to start. So I start with a couple of observations and questions.
I don't have Qt experience yet, but I used Gtk+ and Hildon on Diablo and Fremantle a lot. I've also used Hildon a lot during the Beta phase of Fremantle (starting from the first version with UI support). From what I learned with the Fremantle Beta SDK, I feel save to say, that once a SDK with UI support is released it's definitively too late to change anything substantial. Unfortunately I'm quite sure it's already too late for Harmattan even without a SDK release. So we will have Dui* widgets and we will have Q* widgets. That's not too bad yet. The question is, how deep/thick is this UI layer? I mean we have to redesign the UIs anyways between different platforms. So to me the main question is: How much of the backend code needs to be changed? And if I'm talking about backend, I don't mean stuff like a database or a sort algorithm. I'm talking about the UI backend like callbacks/slots. Is there some compatibility between Dui* and Q* widgets? For example, does QPushButton and DuiButton both implement a common Button interface? I mean, I don't really care whether a Button is implemented using the QGraphicsView or not. To me it's still a button. I can set a label, an image, etc. and whenever it's clicked it will send out a "clicked" signal. If now the DuiButton and the QPushButton send the same "clicked" signal. My UI backend is happy because I don't have to change it. But if the QPushButton sends a "qClicked" signal and the DuiButton sends a "DuiClicked" signal, then we have a problem because those "small UI" changes will ripple through our complete applications. And of course it's not only signals, it's parameters send with the signals and methods called on the widgets. Unfortunately I'm quite sure I already know the answer. The "pressed" signal which I find in duibutton.h has probably nothing to do with the "pressed" found in QAbstractButton. At least I cannot find any signs about that looking at the code. And that is bad. Really. Before I had a closer look at the code and this thread I was imagine it would work approximately like this: As a developer I'm writing my code on one platform (e.g. Maemo). A very thin UI layer is separated into one file. Or one file per window. Those files are code or XML. Handwritten or created by a designer tool. But those files really only contain what the user is seeing. So only stuff that could be made by a graphical UI designer tool. Then I implement the rest of the application. When I'm done. I fire up the Symbian UI editor and create a UI for Symbian. And that's basically it. In the background there would be factories which create DuiWidgets or QWidgets but to me they just look like Widgets. Now if I need to invoke the Widget::setSuperTransparentAnimation() method which is only available in DuiWidgets. Then I would just cast my Widget to DuiWidget and invoke that method. This way I could selectively use Maemo or Symbian specific code whenever I need it. And only when I need it. I hope I was not too confusing ;) I'm tired and if I talked BS, I'm sorry. Anyways, I think this is the single most important thread at the moment. And we should give the people on the devel-mailing list a hint that it exists. Well, in the end it looks like Conboy will use Gtk/Hildon still a bit longer.... |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
Of course there also might be the need for different APIs, but that does not mean that you should have two _completely independent_ APIs with two completely different inheritance trees. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
Maybe C/Gtk+ wasn't the right technology to do a proper OO API; but Qt supposedly is. Indeed, the earlier Qt porting efforts did exactly this. I don't care - in fact, I expect - to have to change the layout and content of my app for different platforms. I DO NOT WANT to have to learn 3 different APIs to put a button on screen depending on whether I'm targetting a desktop, Symbian or Maemo app. Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
You can use plain Qt QGraphicsWidgets and QGraphicsItems in DUI containers.
http://doc.trolltech.com/4.6/graphicsview.html |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
A quote I picked up on twitter the other day which I really liked and seems very appropriate here:
Quote:
I was going to point out, again, that it's perfectly possible for two very different looking platforms, even with different interaction models to have a common core API. The reason being because you're not innovating so radically in UX that we no longer have basic concepts like lists and buttons - even if Harmattan does make a giant leap forward. However, it seems plenty of others are on the same page and have beaten me to it. Considering Hildon's first incarnation as yet another UI framework for Symbian (Series 90) that no-one wanted to write apps specifically for, you'd have thought Nokia might have learned this lesson by now. Quote:
Quote:
Quote:
Developers can of course build their own QGraphicsWidget set in pure Qt. It's a lot of work. However, if their apps want to integrate well into Maemo and Symbian then they may well want to integrate with the theme engine - which is presumably separate again on each platform (I'd love someone to come and tell me otherwise, since we are surely in the realms of pure Qt here). Suddenly it's becoming a massive amount of work. Being able to use custom QGraphicsItems and QGraphicsWidgets in the Maemo containers doesn't help at all (well you could possibly port Symbian ones to Maemo or vice versa - but that's not going to give the platform look and feel). Of course it's all built with Qt, so it does mean you can have a lot more code reuse than you got historically, but we're still a very long way short of the cross-platform promise. Mark |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
For those who are worried about compatibility of the QWidget based widgets in Dui, you might be interested in about the itemview-ng project in Qt Software.
Their goals is to make all the Q*Widgets to run natively on QGraphicsView. I guess this would solve most of the problems discussed here related on code compatibility. I don't want comment anything about having to different platforms here because I couldn't care less about symbian stuff:) See Thiago's comment on Qt labs discussion: ": to have all of the widgets available “natively” in Graphics View, to have them accessible from QML and to have native styling. As for CSS, we’re probably just going to ditch that in favour of QML." They will also introduce similiar kind of MVC model than DUI does. You can checkout the source code from git and check the examples. More information: http://labs.trolltech.com/blogs/2009...-have-liftoff/ http://qt.gitorious.org/qt-labs/itemviews-ng For me this sounds quite good. What do you think? I'm not sure if this "feature" will be available for Maemo 6... Addition:One thing came to my mind that there will be two different MVC mechanism when both Dui and Qt releases their systems. Instead of having two almost identical systems, could they put effort to develop only one, but make it really good? |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Hi zchydem,
Quote:
Quote:
Quote:
Mark |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
I'd like to point out (as many probably already are aware of) that Qt code will be source compatible as long as its running on a supported platform.
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Hi dubik,
Thanks very much for coming to get involved in the conversation. Quote:
Quote:
Quote:
What about one of the comments on this thread, is DuiApplication really needed, or can things be pushed back into the private implementation of QApplication? I realise the libdui guys can't do that on their own, but in theory? |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
please...
Having two differing widgets/application based on the same codebase is only a minor inconvenience, easily handled with #ifdefs and differing ui forms, if even needed. Heck, you can even load the ui forms at runtime, offering the ability to change the gui without recompiling. Not to mention Qt Kinetic. The same differences have existed between Qt, Qtopia, and KDE for a decade, and I have personally been there, and done that for the last decade (think Sharp Zaurus 5000D). It's not that difficult, really. I don't think it's a big of a deal as you make it out to be. I wrote an app - Gutenbrowser, that can be run on Qtopia, Qt desktop, Qt embedded, KDE, or whatever. (Although the Qtopia code has been abandoned for obvious reasons). It wouldn't be all that difficult to bring back the QtopiaApplication, if the need arises. Don't make mountains out of mole hills. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Here we go again. Nokia never learns from its past mistakes.
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
I really like the direction that the itemview-ng project is heading for. And definitely qml is the greatest addition to Qt stack since webkit. Qml finally allows separation of UI and business logic in a way that makes sense (which is that there is also scripting for the UI so that almost all user interaction can reside in the script portion of the application). With qml and especially the itemview ng, there is true portability of at least the UI level.
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Oh, and as someone commented on the broken gdb, we are finally updating that (yay!) to 7.0.
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
Quote:
Quote:
Qt will take some parts from libdui but it's not going to happened before 4.7 as far as I know (or at least make alternative implementation). |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
Quote:
Quote:
I've ported Qt apps between platforms and added platform-specific stuff - even for the rather different strand that was Qtopia, the changes are still very minor. This Dui stuff is in a different ballpark in terms of effort as far as I can see, contrary to what Lorn Potter is suggesting further up the thread. Qt Mobility is obviously going to take some time to get really good functionality coverage as they have to write separate backends for each platform, but if UI code can't be cross-platform from day 1, what can? Quote:
Let my try to make it clear how much of a disconnect there is between the strategy (at least as I understood it) and the implementation. At the presentation on the selection and acquisition of Qt (and reasons for) at the Nokia Developer Summit in Monaco last year, it stated that Nokia realised they were building 4 or 5 versions of each of their applications and this was incredibly wasteful - what's more, 3rd party developers would have the same problem. They immediately ditched Series 80 and 90 and then started working on a replacement cross-platform framework plan for the remaining platforms so they could build applications and services once that worked across the entire portfolio. They bought Qt and everyone was happy. :) It's really important that Symbian and Maemo be compatible. Symbian has a real shortage of decent free apps and Maemo has almost no decent commercial apps. If most apps are trivially portable between the two then both will get a significant benefit. If not, many commercial developers won't bother with a Maemo port initially because of the low volumes and we aren't likely to see many ports of free software to Symbian either (because as we've seen in this thread, most free software guys don't care about Symbian). I thought this was very clearly understood. Indeed just in December Peter Schneider was speaking at the same developer event as me in Sweden and said that Maemo is depending on Symbian's volumes to get the commercial app developers in the first couple of years. However, if you need to do a complete UI re-write - is that really going to happen. It certainly didn't on Symbian for S60 vs UIQ in most cases. Now maybe the plan is still as I thought it was and all of this is just interim measures while Qt evolves to cover the new UI paradigm and mobility stuff? If that was genuinely seen as a business necessity then what thought has gone into what 3rd party developers should do? Forum Nokia is telling everyone to start working with pure Qt now? Is that going to produce the results anyone wants? |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
I develop libdui on Mac, rest of people use Ubuntu, we have it running on Windows, to me it looks like it runs on many platforms. You are asking for sources compatibility between Orbit and DirectUI but at the same time you ask sources compatibility even with plain QT! Btw, there are no widgets based of QGraphicsWidget in QT. So, shell we still discuss source compatibility with plain QT? Quote:
Quote:
Quote:
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Wow, that says it all. We're coming at this from very different perspectives.
Personally I see this as an extremely dangerous attitude coming from a very flawed analysis of the mobile app development space: Quote:
What really worries me there is that someone working on the UI framework actually believes the frameworks don't matter - the app developers will come anyway! Or am I reading that wrong? Quote:
Quote:
http://qt.nokia.com/doc/4.6/qapplica...QApplication-6 Quote:
Quote:
Quote:
Will the future Symbian UI framework always have softkey labels next to where the physical soft keys would be if there were any? I certainly hope not! Quote:
I'm not completely unrealistic (at least I didn't think I was) - I don't expect there to be 100% source compatibility for everything you can do with the UI. For example soft keys, if available, can have an extra API that you only use if you want to set softkey labels to something other than the default values, much as exists in the current Qt port to S60. What's the point of having Maemo and Symbian? For a company the size of Nokia, not putting all your eggs in one basket seems like part of the reason. Another is that they have different strengths and weaknesses for addressing different market segments. Maemo is easier to port to high-end hardware and much easier to create a product that's closer to a netbook or laptop type of computing experience. Symbian is better for building a smartphone - it does the phone bit very well, including the ability to run the signalling stack on the same chip, which is not so easy in Linux. That's part of what lets Symbian reach much further down the price band than Maemo. However, what was made clear in the Nokia Capital Markets day is that the market segments for Maemo and Symbian do have some substantial overlap too (at least if you can read anything into the pretty graphs). I really don't see the UI as a good place for the two platforms to make radical departures from one another, since Maemo will surely want people upgrading from a Symbian device to make up a lot of its future user base? However, in this area I have to admit to pure speculation, since we're all still in the dark about future devices out here! :) Even though we're coming at this problem from very different places, I hope we can find some common ground and work together to make porting between platforms as simple as possible for 3rd party developers. I get the impression from the interest this thread has generated that I'm not the only one who thinks this is very important. I'll not say anything more on the subject until I've got some Symbian code for comparison, then I'll start a new thread with some analysis. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
platform to be succesful (from the amount of applications point of view) and you are making conclusion that I (as a person) think that framework doesn't matter. Not to mention your dramatic remarks: "really worries", "extremely dangerous attitude". Quote:
Quote:
original app: QApplication app(argc, argv); for symbian you need that factory i guess (lets assume you need it). How are you going to include that as a first parameter without change code significantly? are you going to write something like this? #ifdef _S60 QApplication app(pointerToFactory, argc, argv); #else QApplication app(argc, argv); #endif If you need that factory for S60, I see no reason why you can't change QApplication to DuiApplication for maemo. It's just 3 letters. Quote:
Quote:
Quote:
Quote:
Quote:
|
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
For open source application development, that kind of #ifdefs are bad bad bad. They all should be hidden inside framework code, so the application developer community doesn't need to care. Isn't that the whole point of the framework? Seriously, no to requiring #ifdefs for cross-platform operation! I mean, with enough #ifdefs, every code can be cross-platform... |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
OK, I lost two goes at replying to this to a dodgy network connection on the train last night, so this might be a bit shorter than it should have been.
I said I would say nothing more until we had something to discuss, but since you ask some direct questions... Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
I don't think we're really getting anywhere here though. The requirement I'm looking to fill is cross-platform development of the new paradigm animated UIs, with Symbian & Maemo as a minimum level of supported platforms. My assumption is that at a minimum we need a common set of QGraphicsWidgets for that. I'll test that assumption as soon as I can, then we can talk details. |
Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
Quote:
Quote:
Quote:
Quote:
I have given you a solution to your problem, and a way that this is not really a problem and you have tried everything to look the other way. |
All times are GMT. The time now is 06:13. |
vBulletin® Version 3.8.8