Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (3)
to General by Kalatti - 1 day, 21 hrs ago - more...
konttori |
2010-01-08
, 21:13
|
|
Posts: 1,038 |
Thanked: 737 times |
Joined on Nov 2005
@ Helsinki
|
#111
|
Oh, and as someone commented on the broken gdb, we are finally updating that (yay!) to 7.0.
|
|
2010-01-08
, 23:20
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#112
|
Originally Posted by lpotter
My problem with that was that more complex Qt projects tended to have 'smart' dialogs and forms, many of the actual signals, actions, etc defined in the forms. Which is cool and makes it easier to see what's going on, except if you want to swap in another UI (say, because you were porting an UI to WinCE), it turns into a hellish tar pit. So you had a choice of throwing out the sophistication of QDesigner and do coding UIs head-to-code, like Real Men, 1999 style, or battle the bugs of never-quite-in-sync .UI-s. And peppering code with #ifdefs by design in a multiplatform framework is also a bit of a drag in 2010. For me, thus, the question is not how difficult it is, but rather if it is really necessary or not (we could just as well have a QMacApplication and a QWinApplication, but we don't and that's not because it's hard to put an #ifdef around it). Just my 2 cents
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.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
| The Following 5 Users Say Thank You to attila77 For This Useful Post: | ||
|
|
2010-01-09
, 10:07
|
|
Posts: 14 |
Thanked: 31 times |
Joined on Jan 2010
@ Helsinki
|
#113
|
Originally Posted by Mark Wilcox
Well, how much time did it take to get animation framework into 4.6? Which is fairly simple. I took a look at activity of itemview-ng and there were only few commits during last several months. Trolls are genius but there are not so many of them. May be not years but year - easily. Phone programs can't wait
Really? Years? It seems stuff in Qt-labs typically gets to the mainline a version or two later - maybe Qt 4.8?
Originally Posted by Mark Wilcox
Yeah, I know. But your first post gave an impression that arrogant developers didn't want to cooperate. Which is not true. Lets close this, noone in libdui team (even ex members who are now working in other maemo teams) feared or is fearing to loose his job.
It's never developers that make the decisions at this level - typically someone somewhere in the upper reaches of middle management who hasn't touched code for 5+ years. There's also a big difference between what people fear will happen in a re-org and what actually happens afterwards.
Originally Posted by Mark Wilcox
I don't understand whats the big deal of replacing QApplication with DuiApplication? First, we are trying to avoid mixing Q* and Dui*. Second and it's more important, we need to initialize quite a few services: application prestarting, service framework and so on. I doubt QT guys would like to see that code in QApplicationPrivate
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?
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).
| The Following User Says Thank You to dubik For This Useful Post: | ||
|
|
2010-01-11
, 09:33
|
|
Posts: 12 |
Thanked: 125 times |
Joined on Dec 2009
@ York UK
|
#114
|
May be not years but year - easily. Phone programs can't wait
Yeah, I know. But your first post gave an impression that arrogant developers didn't want to cooperate. Which is not true. Lets close this, noone in libdui team (even ex members who are now working in other maemo teams) feared or is fearing to loose his job.
I don't understand whats the big deal of replacing QApplication with DuiApplication? First, we are trying to avoid mixing Q* and Dui*.
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?
Second and it's more important, we need to initialize quite a few services: application prestarting, service framework and so on. I doubt QT guys would like to see that code in QApplicationPrivate
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?
Last edited by Mark Wilcox; 2010-01-11 at 11:07.
|
|
2010-01-11
, 13:16
|
|
Posts: 14 |
Thanked: 31 times |
Joined on Jan 2010
@ Helsinki
|
#115
|
Originally Posted by Mark Wilcox
You are confusing me. When you say DuiApplication do you actually mean all widgets and classes which directui provides? So you want to create QPushButton, QLabel and have interface like iPhone or android has with all animations, layouts, orientation changes and so on? hm. We have no idea how to do that.
It breaks source compatibility. I can no longer build and test my UI against standard Linux (or Windows or Mac) Qt for a faster compile-debug-edit cycle. Ideally I want to be able to build a large subset of possible applications that look native without going near anything platform-specific. If I have to use platform-specific stuff then it should be a couple of lines with a #ifdef or something I can easily encapsulate using the private implementation pattern.
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?
Originally Posted by Mark Wilcox
In desktop world all your platform have monitor, mouse and keyboard. There is even a standard for keyboard layout. In mobile world it's total mess. Sometimes you have keyboard, sometimes don't, some have multitouch, some don't. Screen sizes and resolutions are so different. I just don't see how someone can create a UI framework which will be suited for different looking products. In Symbian you have soft keys. Thats the only platform which has softkeys (may be S40 another one actually). I doubt maemo also want to have softkeys in their applications. At least n900 happily survives without those. There are millions of such details. Can you immidiately recognize Symbian device? I bet you can. Doesn't matter what theme is installed, what collors or applications. You just notice that immediately. That will happen to common UI framework. Maemo device will look like Symbian. Whats the point of having maemo then? bash?
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?
Originally Posted by Mark Wilcox
Not really. Private implementation pattern is just to keep implementation really private and provide ABI. But ofcourse you can build hierarchy of _really_ private classes around it. One for maemo, one for desktop. I just don't see how it can work, not technically but in practice. What if we need additional parameter, like service name which we introduced into DuiApplication?
Well, if these things really need to be initialized separately for every Maemo application then there should be a Maemo-specific implementation of QApplicationPrivate - surely that's exactly what the private implementation pattern is for?
Originally Posted by Mark Wilcox
I said it many times and will repeat again. It's not important what kind of frameworks device or platform has. If there are millions devices and something like ovistore which gives 70% revenue to developers there will be all kind of apps. Android and iphone proves it. Even palm proves it. Can you port open source twitter client to palm? I bet you can't even run it on device. (and you actually can run almost any open source app on n900, gtk, qt, tcl and so on). And still they have apps which are coming to store. And thats because of money not because of great WebOS.
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.
Originally Posted by Mark Wilcox
You will be able to run native qt on harmattan without any changes to sources. I said that on maemo summit in amsterdam. And we are working hard to get it as native as possible to maemo 6 ui. So if you want to hack few things, you may just recompile your QT app. Otherwise you have to port. I also heard that maemo 5 supports native qt nicely as well.
Forum Nokia is telling everyone to start working with pure Qt now? Is that going to produce the results anyone wants?
Last edited by dubik; 2010-01-11 at 16:22.
|
|
2010-01-11
, 16:09
|
|
Posts: 12 |
Thanked: 125 times |
Joined on Dec 2009
@ York UK
|
#116
|
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:
Native Symbian code has around 300 million devices total, at least half of those are running recent versions of S60 and are out there in the market now. How many people want to develop apps for them and what's the level of activity there now? Android is a total counter-proof to your claim. Hardly any devices at all sold relative to other platforms and yet the second most apps of anything but the iPhone. Palm is the only thing with fewer sales and it actually has very few apps compared to the other US platforms, largely because it only has a web-scripting environment (well actually they just added native plug-ins) - which is what had early iPhone developers screaming for a proper native SDK.
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?
What I'm looking for here is not changing APIs significantly without a very good reason. So I'm not talking about the whole thing, just QApplication vs DuiApplication. I'm not expecting you to make a next generation UI without using the graphics view architecture and animation framework.
Two possibilities spring to mind immediately, one is that you could pass something in using the standard command line arguments... people did that for decades with main() without needing to modify the entry point. The other is that you could get another parameter added to QApplication - it seems there's an S60-specific one already:
http://qt.nokia.com/doc/4.6/qapplica...QApplication-6
Does libdui have no dependencies other than Qt - it's actually running natively on those platforms, not in some Maemo emultor? If so, it's better than I feared, although still not as good as I hoped. If libdui is actually cross-platform then there may be some hope of fixing things quite quickly. I know the Symbian^4 UI framework is mostly definitely not - for example I checked up on the theme server, it's implemented as a native Symbian server, so it's not going to run anywhere else.
Desktops can also have touchscreens with multi-touch now, and they might not have a physical keyboard - we have tablet PCs. Screen sizes and resolutions also vary massively too. I agree that the challenges are greater in mobile, but they aren't as different as you suggest. Qt has been working across all PCs and several other very different looking types of device for many years. They have always tried to minimize API fragmentation. I'm sure they plan for that to continue with the animated UI paradigm. I can accept an argument that says it couldn't be done quickly enough, but not one that says it can't be done.
If there are millions of such details please can you at least provide a valid example? Not all Symbian devices have physical soft keys - the rigidity of the Avkon UI framework is what makes it easy to recognise and also what produces a lot of the weakness of the 5th Edition touch UI. It's not a good thing!
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!
No! Does a Qt application running on Mac OS X look like a Qt application running on KDE? There are two completely separate things here - one is look and feel, which should be encapsulated in a style guide and the look and behaviour of widgets. The other is the API you use to program the UI. If you get the level of abstraction right the two are fairly loosely coupled. The framework should not enforce the style guide rigidly (as Avkon does).
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.
Personally I see this as an extremely dangerous attitude coming from a very flawed analysis of the mobile app development space:
I said it many times and will repeat again. It's not important what kind of frameworks device or platform has. If there are millions devices and something like ovistore which gives 70% revenue to developers there will be all kind of apps. Android and iphone proves it. Even palm proves it. Can you port open source twitter client to palm? I bet you can't even run it on device. (and you actually can run almost any open source app on n900, gtk, qt, tcl and so on). And still they have apps which are coming to store. And thats because of money not because of great WebOS.
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?
You are confusing me. When you say DuiApplication do you actually mean all widgets and classes which directui provides? So you want to create QPushButton, QLabel and have interface like iPhone or android has with all animations, layouts, orientation changes and so on? hm. We have no idea how to do that.
Not really. Private implementation pattern is just to keep implementation really private and provide ABI. But ofcourse you can build hierarchy of _really_ private classes around it. One for maemo, one for desktop. I just don't see how it can work, not technically but in practice. What if we need additional parameter, like service name which we introduced into DuiApplication?
http://qt.nokia.com/doc/4.6/qapplica...QApplication-6
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!
In desktop world all your platform have monitor, mouse and keyboard. There is even a standard for keyboard layout. In mobile world it's total mess. Sometimes you have keyboard, sometimes don't, some have multitouch, some don't. Screen sizes and resolutions are so different. I just don't see how someone can create a UI framework which will be suited for different looking products.
In Symbian you have soft keys. Thats the only platform which has softkeys (may be S40 another one actually). I doubt maemo also want to have softkeys in their applications. At least n900 happily survives without those. There are millions of such details.
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!
That will happen to common UI framework. Maemo device will look like Symbian. Whats the point of having maemo then? bash?
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.
|
|
2010-01-11
, 17:15
|
|
Posts: 14 |
Thanked: 31 times |
Joined on Jan 2010
@ Helsinki
|
#117
|
Originally Posted by Mark Wilcox
Are you a yellow newspaper journalist or what? You are following weird logic. I'm talking about app stores and what's important for a
Personally I see this as an extremely dangerous attitude coming from a very flawed analysis of the mobile app development space:
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?
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".
Originally Posted by Mark Wilcox
I'm not following you. What's your point? Symbian doesn't have many applications because it's framework is bad or because it doesn't have app store (where profit is split 70 by 30)?
Native Symbian code has around 300 million devices total, at least half of those are running recent versions of S60 and are out there in the market now. How many people want to develop apps for them and what's the level of activity there now? Android is a total counter-proof to your claim. Hardly any devices at all sold relative to other platforms and yet the second most apps of anything but the iPhone. Palm is the only thing with fewer sales and it actually has very few apps compared to the other US platforms, largely because it only has a web-scripting environment (well actually they just added native plug-ins) - which is what had early iPhone developers screaming for a proper native SDK.
Originally Posted by Mark Wilcox
So, how your QT application will look like then if you would want to port it to Symbian?
What I'm looking for here is not changing APIs significantly without a very good reason. So I'm not talking about the whole thing, just QApplication vs DuiApplication. I'm not expecting you to make a next generation UI without using the graphics view architecture and animation framework.
Two possibilities spring to mind immediately, one is that you could pass something in using the standard command line arguments... people did that for decades with main() without needing to modify the entry point. The other is that you could get another parameter added to QApplication - it seems there's an S60-specific one already:
http://qt.nokia.com/doc/4.6/qapplica...QApplication-6
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.
Originally Posted by Mark Wilcox
It runs natively.
Does libdui have no dependencies other than Qt - it's actually running natively on those platforms, not in some Maemo emultor? If so, it's better than I feared, although still not as good as I hoped. If libdui is actually cross-platform then there may be some hope of fixing
Originally Posted by Mark Wilcox
Yeah, I also saw tablets with win7. It's ridiculous. Old UIs are not suitable for finger oriented interfaces. It's just proves my point. Btw, almost all vendors create their own UI shells for those device to browse pictures and so on. Do you know why?
Desktops can also have touchscreens with multi-touch now, and they might not have a physical keyboard - we have tablet PCs. Screen sizes and resolutions also vary massively too. I agree that the challenges are greater in mobile, but they aren't as different as you suggest. Qt has been working across all PCs and several other very different looking types of device for many years. They have always tried to minimize API fragmentation. I'm sure they plan for that to continue with the animated UI paradigm. I can accept an argument that says it couldn't be done quickly enough, but not one that says it can't be done.
Originally Posted by Mark Wilcox
Well, they all have physical soft keys, just sometimes it's part of screen. Another example is missing hardware "home" key in n900. When there is no such a key _all_ application should have "home" button. I wonder how you would do that with Avkon.
If there are millions of such details please can you at least provide a valid example? Not all Symbian devices have physical soft keys - the rigidity of the Avkon UI framework is what makes it easy to recognise and also what produces a lot of the weakness of the 5th Edition touch UI. It's not a good thing!
Originally Posted by Mark Wilcox
Actually yes. They do look the same. I see label here, scroll bar there. It's all the same, except that they are drawn differently. If you look at mobile frameworks, they all enforce certain style guide. For instance framework enforces where menu of application will appear.
No! Does a Qt application running on Mac OS X look like a Qt application running on KDE? There are two completely separate things here - one is look and feel, which should be encapsulated in a style guide and the look and behaviour of widgets. The other is the API you use to program the UI. If you get the level of abstraction right the two are fairly loosely coupled. The framework should not enforce the style guide rigidly (as Avkon does).
Originally Posted by Mark Wilcox
This approach even worse. Sometimes things just don't exist, like soft keys but sometimes they don't match partially and then you get a mess. Because you need several copies of "almost" same things.
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.
|
|
2010-01-12
, 08:51
|
|
Posts: 6 |
Thanked: 20 times |
Joined on Jan 2010
|
#118
|
Originally Posted by lpotter
I just want to point out, that unless you're running a professionally managed software project with developers and testers and test devices for all branches of that #ifdef tree (hopefully just two, but...), code inside #ifdefs is a big problem. If you need to change it, you often have to change all branches. But if you can't conveniently test it, can't possibly even check if it compiles without installing a new full cross-platform SDK, how confidently can you make the change? Or do you just add #error on the #ifdef branch you didn't touch, so the next person compiling for the other branch is force to fix that branch too?
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.
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...
|
|
2010-01-12
, 12:15
|
|
Posts: 12 |
Thanked: 125 times |
Joined on Dec 2009
@ York UK
|
#119
|
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...
No, I'm not a journalist trying to stir up trouble. I really want Nokia to continue to stay on top in the smartphone race. I see them as infinitely preferable to alternatives like control freak Apple or Google's ad-filled, privacy-free distopia. I just happen to believe that Nokia have a great strategy to do that which isn't working out as it should. I find that extremely frustrating and disappointing - hence the emotive language.
Yes, exactly that. At least it doesn't have as many applications as it should considering the device volumes compared to the competition. To clarify, in case I get misrepresented in some industry blog again, Avkon is not well suited to touch UI devices and Symbian C++ and the Avkon APIs are too complex to learn and use for most developers. This makes it both less economically viable and less fun to do - so people are less likely to do it. The Ovi store has improved things, but nowhere near as much as would be expected if the two factors you suggest were the only important ones.
No, I think it's a special case. Most apps can just use the standard QApplication constructor.
Fantastic! That's a good start.
Yes, standard win 7 on tablets is bad - I agree. I bet the trolls could create a QTabletPCStyle that produced good looking apps from standard Qt code though. To get them looking really great you might need to change the layout, but otherwise the code wouldn't need to change.
If it's part of the screen it's not a "physical" soft key. That's the point, they're there in 5th Edition because the framework is too inflexible to allow the apps to do anything else easily.
I'm not sure I get your point here - Avkon has an "end" key that takes you "home", and a "menu" key that takes you to the main menu. Whatever your framework, it needs to intercept some commands before they get to the app - whether they be from physical keys, virtual keys drawn by the framework, or gestures (touch or other sensor, e.g. accelerometer). Every framework does this but it's not typically visible in the API, is it?
OK, I picked two examples that were too close together for you. What about Qt on desktop systems and the current Qt port to Symbian/S60. On Symbian, the standard code to create your menu for a desktop puts it on the options softkey by default (no extra softkey API needed for that). As long as the UI framework APIs have the right level of abstraction, they can be the same across very different looking platforms.
In my experience this is a sure sign that your API is at the wrong level of abstraction and it's time for some re-factoring.
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.
Last edited by Mark Wilcox; 2010-01-12 at 12:18.
I said I would say nothing more until we had something to discuss, but since you ask some direct questions...
Are you a yellow newspaper journalist or what? ... Not to mention your dramatic remarks: "really worries", "extremely dangerous attitude".
What's your point? Symbian doesn't have many applications because it's framework is bad
for symbian you need that factory i guess (lets assume you need it).
It runs natively.
Yeah, I also saw tablets with win7. It's ridiculous. Old UIs are not suitable for finger oriented interfaces. It's just proves my point. Btw, almost all vendors create their own UI shells for those device to browse pictures and so on. Do you know why?
Well, they all have physical soft keys, just sometimes it's part of screen.
Another example is missing hardware "home" key in n900. When there is no such a key _all_ application should have "home" button. I wonder how you would do that with Avkon.
Actually yes. They do look the same. I see label here, scroll bar there. It's all the same, except that they are drawn differently. If you look at mobile frameworks, they all enforce certain style guide. For instance framework enforces where menu of application will appear.
This approach even worse. Sometimes things just don't exist, like soft keys but sometimes they don't match partially and then you get a mess. Because you need several copies of "almost" same things.
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.
Last edited by Mark Wilcox; 2010-01-12 at 12:18.
|
|
2010-01-12
, 19:43
|
|
Posts: 63 |
Thanked: 52 times |
Joined on Jan 2006
@ Brisbane, Australia
|
#120
|
Originally Posted by arlehyn
I managed to do this fine by myself just fine for many years.
I just want to point out, that unless you're running a professionally managed software project with developers and testers and test devices for all branches of that #ifdef tree (hopefully just two, but...), code inside #ifdefs is a big problem.
If you need to change it, you often have to change all branches. But if you can't conveniently test it, can't possibly even check if it compiles without installing a new full cross-platform SDK, how confidently can you make the change?
Or do you just add #error on the #ifdef branch you didn't touch, so the next person compiling for the other branch is force to fix that branch too?
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...
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.
__________________
Programmer, connectivity, sensors, Jolla/llornkcor technologies
Programmer, connectivity, sensors, Jolla/llornkcor technologies
| The Following User Says Thank You to lpotter For This Useful Post: | ||
 |
| Tags |
| cross-platform, dui, future, harmattan, libdui, maemo, maemo 6, plain qt, programming, source compatibility, symbian |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 22:35.