Re: Qt Autorotation
Hello, On Thursday 03 of June 2010, Kimmo Hämäläinen wrote: > Yes, the WM makes sure that transient dialogs "inherit" portrait > properties from the parent (meaning the window they are transient for). > Of course, you could also put the window properties to the dialog window > itself to have the same effect with a system-modal (non-transient) > dialog. I believe you misunderstood the problem: The original problem was that new windows would not respect the current state. If you create a new dialog and set it to auto-rotate, the new dialog will show up in landscape mode even if the display was in portrait mode. It is a common problem that affects pop-up dialogs. It can be bypassed by setting a parent window and Felipe explained why. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Autorotation
Hello, On Thursday 27 of May 2010, Felipe Crochik wrote: > Luca, > I ran into the same issue - the new windows always start on landscape - and > used the same workaround - checked the screen resolution and when taller > set the portrait attribute. And yes, I believe you are right, setting the I had the same problem but it proved to be my fault. If you are using QDialogs like me then you only have to be sure that you're setting the main window (the one with the portrait mode support) as the parent window. This will give nice portrait support and QDialogs will start in the proper condition. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: proper icon path
On Tuesday 06 of April 2010, daniel wilms wrote: > ext Stefanos Harhalakis wrote: > > I'm currently using /usr/share/icons/hicolor/64x64/apps/, but I see other > > applications using /usr/share/icons/hicolor/64x64/hildon, or even > > /usr/share/icons/hicolor/scalable/apps and > > /usr/share/icons/hicolor/scalable/hildon. > > > > Is there a "proper" location or is everything acceptable? > > The proper location for the icons is in: > > /usr/share/icons/hicolor/scalable/hildon/ Thank you for clarifying that. Is there a reason why "scalable" was chosen? AFAIK for desktop systems this is supposed to hold "scalable" graphics like SVGs while bitmaps icons are supposed to go under /usr/share/icons/hicolor/AxB/ (AxB being the dimension) (or perhaps I know wrong). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
proper icon path
Hello, I'm trying to figure out which is the proper icon location for menu icons. I'm currently using /usr/share/icons/hicolor/64x64/apps/, but I see other applications using /usr/share/icons/hicolor/64x64/hildon, or even /usr/share/icons/hicolor/scalable/apps and /usr/share/icons/hicolor/scalable/hildon. Is there a "proper" location or is everything acceptable? I also noticed that putting an icon under hildon/ dirs makes it usable (visible) without requiring a reboot / hildon-desktop restart with PR>=1.1. Is this correct? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Friday 12 of March 2010, Ville M. Vainio wrote: > On Fri, Mar 12, 2010 at 1:49 AM, Stefanos Harhalakis wrote: > > What's the reasoning of asking 10 people to do the same thing? This is > > now popularity contest instead of a QA process. Popular apps among > > developers (techie guys) advance. Non-popular apps wait. > > I have suggested a solution for this problem before on IRC, but here it is: > > Have an app that: > > - Lists apps that need votes (i.e. apps in extras-testing) > - Allow installing that app with few clicks > - Provide way to give feedback & vote for that app > > This would make app testing something you can do in a relaxed fashion > when you are passing time, and feasible also for nontechnical people. It sounds like a very good thought and most probably will improve the current situation a lot. However, I still find the 10 votes to be 8-too-much. It's like provoking people to act irresponsibly by implying that a vote is not that important. Having a testers squad who's approval (sponsoring a'la Debian) (only from 1 or 2 persons) will be required is probably the next best approach after having 2 Nokia employees to do this job. IMHO, streamlining application promotion (and development) should be a high priority for all mobile platforms. Great app repositories and satisfied developers are two of the things that actually improve sells and distinguish platforms. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 of March 2010, Graham Cobb wrote: > The community needs a place where **every** app passes through a very basic > QA to try to make sure it is safe and it is then available. That is what > Extras is. IMHO, that's not extras. Currently extras is the elite of maemo's software. Explaining: Asking for 10 votes for each version of each application is something that I call paranoia in software development. For example: I've a fully optified app that works without problem, but will never be promoted to extras because there are not enough developers with interest in it (more specifically: women). But the audience of extras is very different and there would be interested audience if it were there. What's the reasoning of asking 10 people to do the same thing? This is now popularity contest instead of a QA process. Popular apps among developers (techie guys) advance. Non-popular apps wait. Assuming that the QA process is a serious process, asking 10 people to do the exact same thing isn't serious. If the check is performed correctly, you should need at most 2 persons. If the check if not performed correctly then 10 is not enough. I suggest you take a look at debian's method. Having a kind of maemo- developers that act responsibly, certifying applications would be a good solution. Currently the vote of a person without any programming abilities is the same with a person's that can program and have performed the checks. The best solution IMHO would be for Nokia to have 1 or 2 people to do this job responsibly instead of relying on statistical methods. That would also be very good support of the community efforts and would boost software development. After all, the applications in extras is a big part of the (future) value of maemo/meego. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hello, On Wednesday 24 of February 2010, Dave Neary wrote: > Sascha Mäkelä wrote: > > I was under the impression that for many Qt apps a simple repackaging > > will do the trick. If this is the case, would it not make sense to make > > those updates available? After all, before the updates are released to > > Extras, many users are going to have Qt apps that won't work on their > > N900. Surely we want to correct that as soon as possible. And what about > > existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2 > > is released? > > I know of at least one case where Maemo-specific changes were made in Qt > 4.5 for Maemo and are no longer available in Qt 4.6 (related to Hildon > integration). So it is entirely possible that some apps which previously > compiled will not do so after the upgrade. Is this a library-only issue or a system issue? i.e. is the problem in the new qt library or (let's say) in the capabilities of the new system's components (e.g. removed dbus interfaces). If this is a library-only issue, then there is no reason (except from disk space, but /opt should be a viable solution) why you could not have the newer versions of "problematic" libraries coexist with their old versions. For example, one could have both libqt4-core and libqt4-6-core. Old apps will still be linked against libqt4-core while new apps will be linked against libqt4-6-core. Then, at some point at the future (PR1.3 ?) you could completely remove those old libraries. ... then again I do not have much experience on doing such things. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hello, On Wednesday 24 of February 2010, Niels Breet wrote: > - Maemo 5 PR1.2 will ship with Extras enabled by default but will use > distribution: fremantle-1.2 IMHO, it may be better to have a distribution name like freemantle-2 just to not cause confusions if/when PR1.3 (or other) is released. Having 1.2 in name implies that it should be changed in every new PR. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
settings (control-panel) applet in python
Hello, Is it possible to write a settings applet (one that shows in control panel) in python? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /Opt And MyDocs In Your Packages
Hello, Sorry for the broken threading. I just subscribed and the quote is from copy- paste from nabble. > ext Andrew Flegg writes: > > > Although a unionfs solution would be a bit more further dev on Nokia's > > part, it will reduce the developer complexity and gives us a real > > world solution now. I'm sure the community would help as well, with > > patching/building/testing kernel modules (once again, Nokia should > > realise there are clever technical people in the community who could > > help design an optimal (= quick & good) solution if engaged at the > > right time). > > Yes, agreed. Let's give this unionfs thing a shot. I was previously > arguing against it, but only as a long-term solution. As a > Fremantle-only hack, it might be better than the /opt hack. After reading the whole thread I could offer you the following suggestions/thoughts: 1) /opt is not a good solution (tm). You can install large programs there (e.g. openoffice) but you should not install programs that other programs depends to there (e.g. libraries or command-line utils). This means that (according to what I understand from FHS) a program should not depend on another program in /opt. 2) You should consider making /usr/local a separate filesystem and suggest that programs use that instead of /opt. A system can work with most of its programs in /usr/local and you don't need of links, etc. I had a slackware- based system which had almost everything in /usr/local for 8+ years and there weren't any problems at all. 3) If finally you use /opt/maemo, it may be better to suggest some hashing. For example /opt/maemo/foo could be in /opt/maemo/f/foo. 4) unionfs should be a very good and clean solution. I strongly suggest that you don't use UnionFS and you use AUFS. I had a lot of problems and oopses with the former. 5) If you use aufs, it will be a bit tricky to upgrade packages that are installed in / in a consistent way. For example, apt-get upgrade could end up installing things in the other partition. To solve this you should either do a chroot somewhere else (not-good) or use some voodoo magic :-) 6) If you somehow use aufs, it is possible to speed things up a bit. For example, you could: * Create a union of the small (old) / and a X GB partition which is then mounted as / * Mount the small (old) / as /oldroot as read-only. * Prepend /oldroot/bin:/oldroot/sbin:/oldroot/usr/bin:/oldroot/usr/sbin in $PATH * Perhaps use LD_LIBRARY_PATH with /oldroot/lib:/oldroot/usr/lib first. This would make many of the things load directly from /oldroot while be able to fallback to the unionfs (which should not be that slow). Of course /usr/share won't be used directly, but I believe you can live with that. 7) I can report a success story from 5 computer labs with 120 PCs and more than 300 different students using aufs every day for two years now without a problem and AFAIK without a single kernel panic or oops. It is a little different configuration (union of a physical FS and a tmpfs) but it is a good test for AUFS. 8) You could reconsider (or explain) the need and usage of the internal memory (should I call it JFFS2 NAND?) completely. What is it's purpose? Clearly, it is not fit for the / filesystem if N900 is going to be used in a standard unix-way with non-nokia programs and upgrades. 9) If you need this memory to just be able to provide "re-flash" updates/upgrades, then I cannot find a reasonable way to make this work without problems. Upgrading a library in /usr/lib (for example) could break programs. apt and dpkg are far better in handling this. However, this could always act as a fall-back solution (fail-safe), in case something breaks with the other memory. 10) If you want to use this memory for speed-up, then I believe there are a number of ways to do it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
