Re: Unsatisfied with bugs.maemo.org
Am Freitag, den 05.06.2009, 15:25 +0300 schrieb Eero Tamminen: and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. But I think it would be appropriate to note in API documents which widgets aren't supported by our UI guidelines / with themeing. Can you make a bug about that so that can be fixed for Fremantle (or Harmattan) API docs? I second Eero's request. If Nokia is unwilling/unable/whatever to cover all potential theming testcases than unsupported cases should at least be mentioned in the docs. Basically the same with portrait mode; that's why I filed https://bugs.maemo.org/show_bug.cgi?id=4648 about the unclear docs. andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, ext Till Harbaum / Lists wrote: Hi, i am really unsatisfied with bugs.maemo.org. The reason is simple: Just too many bugs are just closed with WONTFIX which basically means: We understand and acknowledge the problem, but we won't spend any time on it. bugs.maemo.org is only the messenger... This would be acceptible if maemo would be a really open plattform and anybody could just fix things. But that's not how maemo works and there's such a huge number of bugs that never get fixed and the same issues appear ever now and then again. I e.g. just filed bug 4630 and should have noticed myself that 1504 was the same one filed june 2007. It was never fixed but was just WONFIX'd. And we are not just talking about some weird feature. We are actually talking about something being documented in the maemo api docs. I think Andre and you can still try with bug 4630 if it relates to the Maemo 5 API. Why is there a bug reporting system if so many bugs end up with WONTFIX? This doesn't make much sense to me. Again, don't kill the messenger. Maemo 5 bug handling has been already a lot more efficient than in previous versions, thanks to people reproducing old bugs in the Fremantle pre-releases. We expect the good responsiveness to be kept once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting the fixes out in new updates. What we have is a bag of bugs still open affecting mostly Diablo. Because of many reasons those bugs were not handled in time or there were no resources to fix them at the time. Now we are cleaning those bugs week after week and yes, this brings lots of WONTFIX among those that are not an issue anymore in Fremantle. It's more a consequence of a past problem than a reflection of a current problem, though. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, Gil Quim (Nokia-D/Helsinki) wrote: ext Till Harbaum / Lists wrote: i am really unsatisfied with bugs.maemo.org. The reason is simple: Just too many bugs are just closed with WONTFIX which basically means: We understand and acknowledge the problem, but we won't spend any time on it. bugs.maemo.org is only the messenger... This would be acceptible if maemo would be a really open plattform and anybody could just fix things. But that's not how maemo works and there's such a huge number of bugs that never get fixed and the same issues appear ever now and then again. I e.g. just filed bug 4630 and should have noticed myself that 1504 was the same one filed june 2007. It was never fixed but was just WONFIX'd. And we are not just talking about some weird feature. We are actually talking about something being documented in the maemo api docs. I think Andre and you can still try with bug 4630 if it relates to the Maemo 5 API. Bug 4630 1504 are about themeing a single Gtk widget aspect. There are many other Gtk widgets and icons which aren't (at least fully) themed although they otherwise work fine. This is because it would require (internally): * UI specifications about these widget features and their themeing * Themeing these things (gtkrc graphics) for all themes according to the specification * Writing test programs for these features (as they're not used by the product itself) * Regular testing that the widget features and themeing work (in all themes) according to the specification Which is quite a lot of extra work for things that aren't used at all in the product itself. So, it's not done. If the community wants the extra widgets / widget features and icons to be themed because they actually have some program(s) that use them, I think its better to handle that as a community project...? Why is there a bug reporting system if so many bugs end up with WONTFIX? This doesn't make much sense to me. Again, don't kill the messenger. Maemo 5 bug handling has been already a lot more efficient than in previous versions, thanks to people reproducing old bugs in the Fremantle pre-releases. We expect the good responsiveness to be kept once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting the fixes out in new updates. What we have is a bag of bugs still open affecting mostly Diablo. Because of many reasons those bugs were not handled in time or there were no resources to fix them at the time. The main reason was that we didn't have regular pre-releases of the software before Fremantle. The situation of what happens after the official release, is similar as with the other Linux Distros, once e.g. Ubuntu releases a new version of its distribution, implementing feature bugs and minor bug fixes happen to the next release having new features (currently Fremantle on Maemo), the old release will get only bugfixes to security and other critical issues and eventually even those stop. Ubuntu does new releases at fixed 6 months schedule and the bugfixes to them stop for them pretty quickly except for the LTS releases. Our schedule differs (much) more. Also, we don't currently provide LTS releases (partly because Nokia business model is different, we sell products whereas most other Linux distros basically sell services). Unlike Ubuntu we have a few bugfix releases (like e.g. Debian has) because our releases happen at longer intervals. Because of the more radical HW platform differencies between the device targets of the Maemo SW releases, we cannot (at least currently) offer as good backwards HW compatibility support as can be done on x86. This is something that we need to work with the community (and is currently being done e.g. in context of Mer). Now we are cleaning those bugs week after week and yes, this brings lots of WONTFIX among those that are not an issue anymore in Fremantle. It's more a consequence of a past problem than a reflection of a current problem, though. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, sorry, but i don't get your point. You say that you'd need tests and things for the themeing and thus you don't do it at all? You mean it's acceptible to not theme them at all and have them look ugly but it's not acceptible to give them a quick/untested themeing? Why? You basically say either we do things perfectly or we do them in the worse possible way. I'd say: If you don't support that feature, then remove it entirely from the libs and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. You could avoid a lot of internal testing if you'd actually make use of the fact that bugs.maemo.org gives you a bunch of external testers. Actually that's what happening here: You provide a library containing functionality that is incomplete and untested. And the community did the testing for you and now tells you that what you deliver is incomplete. And what do you mean by wanting this to be a community project? Is there an easy way the community can replace nokia provided core libraries and theme files? Or do you suggest people should switch to mer if they are unsatisfied with some half-hearted nokia implementation? You say you only fix those features that are actually a problem for your own product and you don't care for widgets that are only used by third party applications. Are you serious? Nokia really isn't interested in supporting third party apps? Support is only provided if there's also a benefit for nokias own applications? Wow ... Till Am Freitag 05 Juni 2009 schrieb Eero Tamminen: Bug 4630 1504 are about themeing a single Gtk widget aspect. There are many other Gtk widgets and icons which aren't (at least fully) themed although they otherwise work fine. This is because it would require (internally): * UI specifications about these widget features and their themeing * Themeing these things (gtkrc graphics) for all themes according to the specification * Writing test programs for these features (as they're not used by the product itself) * Regular testing that the widget features and themeing work (in all themes) according to the specification Which is quite a lot of extra work for things that aren't used at all in the product itself. So, it's not done. If the community wants the extra widgets / widget features and icons to be themed because they actually have some program(s) that use them, I think its better to handle that as a community project...? Why is there a bug reporting system if so many bugs end up with WONTFIX? This doesn't make much sense to me. Again, don't kill the messenger. Maemo 5 bug handling has been already a lot more efficient than in previous versions, thanks to people reproducing old bugs in the Fremantle pre-releases. We expect the good responsiveness to be kept once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting the fixes out in new updates. What we have is a bag of bugs still open affecting mostly Diablo. Because of many reasons those bugs were not handled in time or there were no resources to fix them at the time. The main reason was that we didn't have regular pre-releases of the software before Fremantle. The situation of what happens after the official release, is similar as with the other Linux Distros, once e.g. Ubuntu releases a new version of its distribution, implementing feature bugs and minor bug fixes happen to the next release having new features (currently Fremantle on Maemo), the old release will get only bugfixes to security and other critical issues and eventually even those stop. Ubuntu does new releases at fixed 6 months schedule and the bugfixes to them stop for them pretty quickly except for the LTS releases. Our schedule differs (much) more. Also, we don't currently provide LTS releases (partly because Nokia business model is different, we sell products whereas most other Linux distros basically sell services). Unlike Ubuntu we have a few bugfix releases (like e.g. Debian has) because our releases happen at longer intervals. Because of the more radical HW platform differencies between the device targets of the Maemo SW releases, we cannot (at least currently) offer as good backwards HW compatibility support as can be done on x86. This is something that we need to work with the community (and is currently being done e.g. in context of Mer). Now we are cleaning those bugs week after week and yes, this brings lots of WONTFIX among those that are not an issue anymore in Fremantle. It's more a consequence of a past problem than a reflection of a current problem, though. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
On Fri, 2009-06-05 at 10:07 +0200, Till Harbaum / Lists wrote: Hi, sorry, but i don't get your point. You say that you'd need tests and things for the themeing and thus you don't do it at all? You mean it's acceptible to not theme them at all and have them look ugly but it's not acceptible to give them a quick/untested themeing? Why? You basically say either we do things perfectly or we do them in the worse possible way. I'd say: If you don't support that feature, then remove it entirely from the libs and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. [...] You say you only fix those features that are actually a problem for your own product and you don't care for widgets that are only used by third party applications. Are you serious? Nokia really isn't interested in supporting third party apps? Support is only provided if there's also a benefit for nokias own applications? Wow ... To be more precise on this topic, it's not that we didn't work on theming of the so-called legacy widgets[1]. Lots of work (and I really mean, *lots* of work) went into making sure that at least the common use cases of these widgets are themed in a consistent way with the new Fremantle style, but as in any project, there are priorities to attend and some issues, like the one you mention, would require a huge effort to get right. You need to understand that we also have time/resources constrains. Claudio [1] That is, widgets that even being part of GTK+ or hildon 2.0, are not recommended to be used for Fremantle because they differ from the new UI style. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, Am Freitag 05 Juni 2009 schrieb Claudio Saavedra: mean, *lots* of work) went into making sure that at least the common use cases of these widgets are themed in a consistent way with the new Fremantle style, but as in any project, there are priorities to attend Ok, here's my problem: Fremantles finger friendlyness is actually the reason why i want those bottom tabs. The desktop version of gpxview as well as the chinook and diablo versions still use top tabs. But when using your fingers it's often difficult to hit a widget precisely. So my solution is to but everything as far apart as possible. As a result i placed the tabs at the bottom to move them away from the BreadCrumbTrail above to notebooks top it. The common use case is imho a problem here as you are asking for finger friendlyness which definitely is not the common use case for gtk widgets and also up to now wasn't the common use case of hildon widgets. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, ext Till Harbaum / Lists wrote: sorry, but i don't get your point. You say that you'd need tests and things for the themeing and thus you don't do it at all? You mean it's acceptible to not theme them at all and have them look ugly but it's not acceptible to give them a quick/untested themeing? Why? To theme something, there needs to be something on which it can be tested. You cannot have a theme for something that doesn't exist on the device (from a graphics artist point of view). UI graphics design is something that starts much earlier than SW development and it moves to future releases much earlier than the SW develoment / bugfixing. By the time there's a public release and public bugs based on it, I don't think there's anymore anybody allocated to do graphics work for that particular release. You basically say either we do things perfectly or we do them in the worse possible way. UI designers aren't clairvoyant. They don't know what specific thing community will want to have been themed few years later. Bugs for previous releases could of course be used as input for this (still needs a test SW though!), but they don't always exist or be appropriate and I don't think that has really been done for graphics like it was done for SW and some UI issues. So, we should improve here. With Fremantle we've started providing regular pre-releases so that things like this can be tested by the community before the release, when there's still time to do also feature requests non-critical fixes for that release. (With the pre-releases you won't see final graphics, but at least it can be tested whether some widget is lacking themeing.) I'd say: If you don't support that feature, then remove it entirely from the libs That would be making them deliberately API ABI incompatible which would kind of make moot the point of using open source components. So, no. and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. But I think it would be appropriate to note in API documents which widgets aren't supported by our UI guidelines / with themeing. Can you make a bug about that so that can be fixed for Fremantle (or Harmattan) API docs? You could avoid a lot of internal testing if you'd actually make use of the fact that bugs.maemo.org gives you a bunch of external testers. Actually that's what happening here: You provide a library containing functionality that is incomplete and untested. And the community did the testing for you and now tells you that what you deliver is incomplete. For graphics the testing needs to happen way before public release of the device. Unfortunately before Fremantle that wasn't possible. And what do you mean by wanting this to be a community project? Is there an easy way the community can replace nokia provided core libraries and theme files? Or do you suggest people should switch to mer if they are unsatisfied with some half-hearted nokia implementation? As the bug is wontfix for Diablo, obviously the only alternative for Diablo is something done by the community. Maybe a new theme based on the default themes on which the app requiring it depends on? Gil, does our theme license allows derivatives? For Fremantle and later releases, community can provide information and working test-cases (applications) for what additional widgets/features should be themed. You say you only fix those features that are actually a problem for your own product and you don't care for widgets that are only used by third party applications. Are you serious? Nokia really isn't interested in supporting third party apps? I was saying that UI designers and graphics artists can fix only problems that they know about, and only if they get to know about them when they still have time to do something about that. Which in case of theme graphics unfortunately is way before the product is released. Support is only provided if there's also a benefit for nokias own applications? Wow ... You can test whether something works, only if you have something that you can test it with. Should be obvious. :-) - Eero PS. It was really annoying/frustrating (not only for 3rd parties, but Nokia developers too) that in earlier products we didn't have regular pre-releases which mean that by the time people were able to test the software and file bugs about it, there wasn't anymore much that could be done about it e.g. feature-wise. Things are much better now with Fremantle. Till Am Freitag 05 Juni 2009 schrieb Eero Tamminen: Bug 4630 1504 are about themeing a single Gtk widget aspect. There are many other Gtk widgets and icons which aren't (at least fully) themed although they otherwise work fine. This is because it would require (internally): * UI specifications about these widget features and their themeing * Themeing these things (gtkrc graphics) for all themes according to the specification
Unsatisfied with bugs.maemo.org
Hi, i am really unsatisfied with bugs.maemo.org. The reason is simple: Just too many bugs are just closed with WONTFIX which basically means: We understand and acknowledge the problem, but we won't spend any time on it. This would be acceptible if maemo would be a really open plattform and anybody could just fix things. But that's not how maemo works and there's such a huge number of bugs that never get fixed and the same issues appear ever now and then again. I e.g. just filed bug 4630 and should have noticed myself that 1504 was the same one filed june 2007. It was never fixed but was just WONFIX'd. And we are not just talking about some weird feature. We are actually talking about something being documented in the maemo api docs. Why is there a bug reporting system if so many bugs end up with WONTFIX? This doesn't make much sense to me. Till (now thinking about ugly workarounds ...) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
