Re: Using glext on n900 and n950?
And for the records: As far as i understand by now the glex lib (if present) just wraps wglGetProcAddress (or similar) which in turn resolves the addresses if the various extensions via their name. So it should just be a matter of calling this getprocaddress function with the correct parameters. Till Am Freitag 09 März 2012 schrieb Kimmo Hämäläinen: > glext.h looks like driver-specific extensions, am I right (at least the > internet seems to tell so)? So there is no guarantee if the driver has > them or not... > > -Kimmo > > On 03/07/12 17:28, ext Till Harbaum / Lists wrote: > > Hi, > > > > i can't figure out how to use glext on n900 or on the n950 using gles1. > > > > As a start i'd just like to access > > glGenFramebuffers() and > > glDeleteFramebuffers() > > > > The only references to this is in GLES/glext.h and the prototypes have > > are named glGenFramebuffersOES and glDeleteFramebuffersOES . So far > > so good. I can compile this. > > > > But i cannot link it. Against what am i supposed to link gles1 applications > > using glext? > > > > Regards, > >Till > > > > -- > > Dr. Till Harbaum > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using glext on n900 and n950?
Since gles 1.1 glex is imho mandatory Till Am Freitag 09 März 2012 schrieb Kimmo Hämäläinen: > glext.h looks like driver-specific extensions, am I right (at least the > internet seems to tell so)? So there is no guarantee if the driver has > them or not... > > -Kimmo > > On 03/07/12 17:28, ext Till Harbaum / Lists wrote: > > Hi, > > > > i can't figure out how to use glext on n900 or on the n950 using gles1. > > > > As a start i'd just like to access > > glGenFramebuffers() and > > glDeleteFramebuffers() > > > > The only references to this is in GLES/glext.h and the prototypes have > > are named glGenFramebuffersOES and glDeleteFramebuffersOES . So far > > so good. I can compile this. > > > > But i cannot link it. Against what am i supposed to link gles1 applications > > using glext? > > > > Regards, > >Till > > > > -- > > Dr. Till Harbaum > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Using glext on n900 and n950?
Hi, i can't figure out how to use glext on n900 or on the n950 using gles1. As a start i'd just like to access glGenFramebuffers() and glDeleteFramebuffers() The only references to this is in GLES/glext.h and the prototypes have are named glGenFramebuffersOES and glDeleteFramebuffersOES . So far so good. I can compile this. But i cannot link it. Against what am i supposed to link gles1 applications using glext? Regards, Till -- Dr. Till Harbaum ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gestures on n950 using QML
Hi, the 1.0 Gesture labs thing also didn't give any events for me ... Till Am Mittwoch 27 Juli 2011 schrieb Felipe Crochik: > Has anybody figured out how to create a qml application that will process > gestures (mainly Pinch)? > The 1.1 documentation suggests that you should use PinchArea but I haven't > had any success with it. > > Thanks in advance for any hints > Felipe > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK 1.1 RC released
Hi, i am mainly using the remote compiler (my broken n900 and the absence of any meego device has made symbian my primary target). This still returns a 4.7.2/1.1.1 binary. Will this also change? Till Am Donnerstag 07 April 2011 schrieb Attila Csipa: > Good news everyone, > > There has been an update on the long road to QtSDK 1.1, but we're almost > there > now - we got the RC today, and the final should not be that far away > > http://labs.qt.nokia.com/2011/04/06/qt-sdk-1-1-rc-released/ > > The differences are mostly bugfixes considering the Maemo side, here's the > generic list: > Qt 4.7.3 is included for Desktop and Symbian > Update to Qt Mobility 1.1.2 > Qt Assistant added as separate package (due to developer request) > Installer can use system proxy on Linux > Notification API moved from experimental to “Additional APIs” > Several fixes for the Qt Simulator > Several fixes for the installation/updating workflow > > This is pretty much it WRT to features expected in 1.1 final, too, the > difference in RC and the final release will be just showstopper bugfixes. > > Best regards, > Attila > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
Hi, Am Montag 01 November 2010 schrieb Matan Ziv-Av: > I think that the start a community SSU should be in consulting with the > community about the goals of this project and the ways to achieve these > goals. Such a discussion needs to take place in a forum that is not real > time, and is archived for future reference. > > I'll start this discussion: > > What is your goal in setting up this SSU repository? Argh, please stop trying to stop people from doing things. If you want to do something differently, feel free to start something on your own. But do not hinder those who actually get something done. Even if you think it's the wrong way they are doing it. Maemo5 has a shrinking developer base and once a MeeGo handset is out the number of Maemo developers will shrink even faster. Be thankful that there still is someone who's actually willing to get his hands dirty ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo builder version problems with geotoad
Hi, i just tried to upload geotoad-3.12.1 to the builder. The ssh upload went fine, but i got no reaction at all. Maybe i am facing version problems? Is 3.12.1 not newer than the current 3.12.0-3? The web uploader also fails as it is incredibly slow and when i finally manage to upload a changes file, it claims the changes file is in wrong format. What's going on here? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Please remove gpxview from chinook and diablo repositories
Chinook still doesn't work. Also the diablo builder is/was broken. After build attempts i got a few emails with subject "[diablo]: gpxview 0.9.6 UNKNOWN" containing some python error messages instead of an actual email content. Also the diablo repo database is broken now. You cannot install gpxview from the repository since the app installer claims that the file length is wrong. Dowloading the .deb from the repository directly via web browser works and installs fine. So the actual package is ok and the meta data is somehow corrupt. Would it be possible to move the diablo/chinook repo maintenance into the hands of some motivated n800/n810 user? The current situation isn't perfect ... Till Am Freitag 27 August 2010 schrieb Andrew Flegg: > Till wrote: > > > > asked to remove libgio and that's where some arguing started > > I don't remember seeing any arguing, but I admit I wasn't paying close > attention. Anyway, the broken libgio has now been removed (Niels, correct me > if I'm wrong) > > Cheers, > > Andrew > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Please remove gpxview from chinook and diablo repositories
Hi, ok, thanks, diablo builds again. Will you do the same for chinook? Regards, Till Am Freitag 27 August 2010 schrieb Andrew Flegg: > Till wrote: > > > > asked to remove libgio and that's where some arguing started > > I don't remember seeing any arguing, but I admit I wasn't paying close > attention. Anyway, the broken libgio has now been removed (Niels, correct me > if I'm wrong) > > Cheers, > > Andrew > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Please remove gpxview from chinook and diablo repositories
Hi, asked to remove libgio and that's where some arguing started. But i don't want to argue. So please remove gpxview and i will just stop supporting it on maemo4. In fact removing all those "#ifdef MAEMO5"'s will nicely clean up the code. Till Am Donnerstag 26 August 2010 schrieb Andrew Flegg: > On Thu, Aug 26, 2010 at 20:53, Till Harbaum / Lists wrote: > > > > i can't compile gpxview against this broken libgio and the libs maintainer > > just doesn't care anymore. > > > > Therefore, please remove all versions of gpxview from the diablo and chinook > > repositories. I can't update the current ones, i can't fix bugs. Thus > > they'd better > > be gone. > > Isn't the issue to complete the outstanding removal of libgio which is > breaking it? Then you won't have any problems. > > Your continued support of Maemo 4 is appreciated, at least by me. > > Cheers, > > Andrew > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Please remove gpxview from chinook and diablo repositories
Hi, i can't compile gpxview against this broken libgio and the libs maintainer just doesn't care anymore. Therefore, please remove all versions of gpxview from the diablo and chinook repositories. I can't update the current ones, i can't fix bugs. Thus they'd better be gone. So please just remove all version of gpxview from the chinook and diablo repositories and i'll stop supporting chinook and diablo. It's already close to a waste of time to support maemo4, but it defintely is a waste of time to have to deal with broken libs when supporting maemo4. And no, i won't hack my config files to explicitely ignore soup2.4 on maemo4. I don't mean to offend anybody, but i am only willing to support maemo4 if i don't have to spend additional effort on this. Regards, Till Am Donnerstag 19 August 2010 schrieb Niels Breet: > Hi, > On Wed, Aug 18, 2010 at 9:19 PM, Till Harbaum / Lists > wrote: > > I have some strange undefined references in chinook/diablo: > > > > https://garage.maemo.org/builder/diablo/gpxview_0.9.4/armel.build.log.FAILED.txt > > > > Is this a know bug or is maemo4 just finally dying? > > It is probably libgio which is broken: > http://maemo.org/packages/view/libgio0/ > > This is a user contributed lib, not part of the default sdk. > > > > > Till > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: diablo/chinook gtk libs in autobuilder broken?
Hi, ok, Faheem doesn't want to support that lib anymore. Would you therefore please remove libgio and all packages depending on it from chinook and diablo repositories. Currently libgio/libsoup24 is in an unusable state, so we don't loose anything. Thanks, Till Am Donnerstag 19 August 2010 schrieb Niels Breet: > Hi, > On Wed, Aug 18, 2010 at 9:19 PM, Till Harbaum / Lists > wrote: > > I have some strange undefined references in chinook/diablo: > > > > https://garage.maemo.org/builder/diablo/gpxview_0.9.4/armel.build.log.FAILED.txt > > > > Is this a know bug or is maemo4 just finally dying? > > It is probably libgio which is broken: > http://maemo.org/packages/view/libgio0/ > > This is a user contributed lib, not part of the default sdk. > > > > > Till > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: diablo/chinook gtk libs in autobuilder broken?
Hi, uhm, sorry, his name is Faheem, of course ... Till Am Donnerstag 19 August 2010 schrieb Till Harbaum / Lists: > Hi, > > ok, i have asked Fayhem about this. What i don't understand: I never had that > problem before. This comes now, since now libsoup2.4 is available for diablo > (up to > now we only had soup 2.2) and this seem to have a dependency on gio. > > But where does this soup2.4 come from? It's in diablo-extras but doesn't have > an owner. How does this happen? > > Regards, > Till > > > Am Donnerstag 19 August 2010 schrieb Niels Breet: > > Hi, > > On Wed, Aug 18, 2010 at 9:19 PM, Till Harbaum / Lists > > wrote: > > > I have some strange undefined references in chinook/diablo: > > > > > > https://garage.maemo.org/builder/diablo/gpxview_0.9.4/armel.build.log.FAILED.txt > > > > > > Is this a know bug or is maemo4 just finally dying? > > > > It is probably libgio which is broken: > > http://maemo.org/packages/view/libgio0/ > > > > This is a user contributed lib, not part of the default sdk. > > > > > > > > Till > > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: diablo/chinook gtk libs in autobuilder broken?
Hi, ok, i have asked Fayhem about this. What i don't understand: I never had that problem before. This comes now, since now libsoup2.4 is available for diablo (up to now we only had soup 2.2) and this seem to have a dependency on gio. But where does this soup2.4 come from? It's in diablo-extras but doesn't have an owner. How does this happen? Regards, Till Am Donnerstag 19 August 2010 schrieb Niels Breet: > Hi, > On Wed, Aug 18, 2010 at 9:19 PM, Till Harbaum / Lists > wrote: > > I have some strange undefined references in chinook/diablo: > > > > https://garage.maemo.org/builder/diablo/gpxview_0.9.4/armel.build.log.FAILED.txt > > > > Is this a know bug or is maemo4 just finally dying? > > It is probably libgio which is broken: > http://maemo.org/packages/view/libgio0/ > > This is a user contributed lib, not part of the default sdk. > > > > > Till > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
diablo/chinook gtk libs in autobuilder broken?
I have some strange undefined references in chinook/diablo: https://garage.maemo.org/builder/diablo/gpxview_0.9.4/armel.build.log.FAILED.txt Is this a know bug or is maemo4 just finally dying? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GoogleCL
Hi, nice! Any examples how to do a google location search with this? Something to use within maep to replace/supplement the geonames search would be great! Till Am Samstag 19 Juni 2010 schrieb Ville M. Vainio: > Anybody gave this a spin on phone already? > > http://google-opensource.blogspot.com/2010/06/introducing-google-command-line-tool.html > > It seems it will provide a trivial, supported way to integrate with > google services. Who will be the first to package it? :) > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Samstag 12 Juni 2010 schrieb Joerg Reisenweber: > It's rather moot, as this isn't a movie at 25fps, so an occasional image > refresh, no matter how it's done, will take magnitudes less energy per time > in > average, than the backlight eats to display the image. When screen is dimmed > (or the widget invisible/hidden/background) then of course all gfx workload > should suspend, for obvious reasons 100% CPU load is bad no matter if this is for a 25fps movie or a 0.5fps 3d map widget. Believe me, i have these discussions regarding maep. People _do_ care for CPU load and battery consumption. And this is good. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Samstag 12 Juni 2010 schrieb Ian Stirling: > And speedups may be very possible - if for example you can offload > portions of the workload onto a GPU. That addresses the performance problem, but this likely also if you do this for performance reasons, it also increases battery consumption as you put additional load onto another component of the SOC. But it may still be good to offload certain tasks from the main CPU to the GPU as the GPU may do the same thing more power efficient. I really think low battery consumption is the most important issue with a map widget as this type of widget is meant to be used over a longer period of time and while being away from stationary power. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Freitag 11 Juni 2010 schrieb Marijn Kruisselbrink: > You might also want to look at the marblewidget (http://edu.kde.org/marble/). > As far as I know it can be built without any kde dependency, and is pretty > powerful. I did. On the n900 as well as on the linux desktop. While i really think this is great for desktops i also think that it isn't the right thing for mobile devices. There are several issues: - It is big and installs ~10MB data - It is pretty complex and doesn't really fit on the small screen - It takes several seconds to load - It runs pretty slow I do understand why people like it, really. But i think the latter two issues are show stoppers. People just won't accept that adding simple map to their programs will cause it to run slow. I have read that poeple are working on the speed issue. But speed alone isn't the problem. More important is battery consumption as those apps tend to be used for a longer period of time. And you wouldn't just have to make it run fast, you'd have to make it run fast without imposing a significant CPU load. Thus i think this whole 3D approach, as cool as it is, doesn't suit the mobile world. All the trigonometrics involved in 3D and the additional CPU load required for proper image stretching/scaling imho doesn't justify the battery drain this will cause. Or am i mistaken and the Marble widget can be switched into some fast and low-CPU 2D mode? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Freitag 11 Juni 2010 schrieb Simon Pickering: > Would a wiki page be useful to determine people's wishes for such a Here we go: http://wiki.maemo.org/QTMapWidget Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Freitag 11 Juni 2010 schrieb tero.k...@nokia.com: > It looks like the people at Qt are thinking of this as well. > http://qt.nokia.com/developer/qt-roadmap/ mentions Maps/Navigation API and > while the details are really scarce (it's only a roadmap, so that is > expected), it does state that: > "Provides an API to access maps, landmarks and route information for > navigation." This also sounds like the wouldn't mind community input/cooperation. > Now just to find some troll from Qt who could open that up a bit. Maybe someone inside Nokia could approach them ... hint, hint ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: QT map widget
Hi, - original Nachricht > I should add that I totally agree with the goal here. The question is > whether it would be better to decide exactly what we want (in terms of > features, hw accelerated rendering, etc.) and write something new, or to > modify an existing piece of code. Exactly that's why i am asking here instead of just start coding like i did with maep. That approach wasn't successful. > Would a wiki page be useful to determine people's wishes for such a > widget? Just thinking off the top of my head there are things like: Sure. But there's one thing we really need to make sure: We need to prevent this from becoming one of those projects that are discussed in every detail without anyone actually doing some work. So perhaps a wiki page make sense, sure. But a garage project with mailing list may be more suitable to keep people interested. > Multiple map sources. Would that include things that are available but > not necessarily fully legal e.g. Google maps - at least it should > provide a way for third parties or users to enable such things? I get frequent requests for user configurable map sources for maep. There are e.g. nice topo maps for finland. Integrating these into the main branch imho doesn't make much sense as these are only interesting for people in finland. I propose some xonfiguration scheme that can be extended just by downloading additional config files from the repositories. Installing "finland topo maps" would then enable those maps in all apps using this widget. > What about deciding what sorts of local POI lookups, routing, traffic > info, etc. might be wanted, and whether it should/can come from online > or local vector map data (e.g. OSM), or even RDS ;) and how these should > be provided. It sure has to be discussed what the widget will provide by itself. These are technical things like GPS integration as well as features like track and waypoint support. I'd say: Technical support for these very common items should be there as e.g. nearly all apps will want to draw something onto the map. It's still to be discussed if even specific waypoint sources should be included into the main map widget. E.g. why should a user be bothered with speed cams in a program displaying bell towers on a map? On the other hand, any program displaying places is intended to be used to get to those places, so navigation may make sense. Also support for very different map types like pre-rendered tiles as well as vector maps sounds great. The finish topo maps would then be a config option for the tile based map renderer. > Overlays are another important point - this was a stumbling block for > Maemo-mapper for a long time iirc. Yes, overlays are very important, even the option for arbitrary ones as you probably won't be able to predict all use cases. I e.g. always wanted to be able to overlay semi-transparent altitude-maps as this would e.g. give some 3d like effect even for google maps. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QT map widget
Hi, with the switch to qt i think there's a need for a qt map widget. I really see a need for a unified widget to be used by all applications. The current situation with multiple different map widgets on maemo5 shows what imho should be prevented: - They store cached tiles at different locations wasting bandwidth as well as device flash space - No central point for map maintenance (e.g. cleaning the map cache or downloading entire areas into the cache for offline usage) - No easy and central way to add new map sources - The overall look and feel is different although they intend to provide similar function - Some widgets work behind network proxies, some don't - None of these widgets is really developer friendly Sampo Savola, the author of ecoach suggested to think about a qt map widget. I am also interested in this as i am the author of osm2go, maep and gpxview. Who else would like to contribute to this? I'd like to make sure that such a widget satisfies most developers need to be able to address above issues with one single qt map widget. A start may be this widget: http://medieninf.de/qmapcontrol/ Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Tetrinet
I once write Mtetrinet http://maemo.org/downloads/product/OS2008/mtetrinet/ Since there were basically no users, i lost interest in maintaining it. But feel free to port it to n900. Till - original Nachricht Betreff: Tetrinet Gesendet: Fr, 21. Mai 2010 Von: Conrad Calmez Hi there, has anyone heard of a Tetrinet port for Maemo 5? I'd be veryinteressted about any possible development that may has happend. I alsowould try to participate (I will need help to do that for sure) on thedevelopment. BR C --- original Nachricht Ende ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Howto grab all Maemo5 zoom key events in SDL/SDL_gles app?
Hi,
i'd like to access the zoom keys in a SDL/SDL_gles app (the 3d globe
i uploaded to extras-devel).
The odd thing is that my solution only partly works. Some key presses actually
reach my app as function key presses, but still most of them reach the volume
control. So when repeatedly pressing the zoom buttons my app zooms but also
the volume is changed.
I am using the following code which is inspired by code from scummvm. I am
calling this code once immediately after the SDL setup is done.
Any idea why this still delivers some key events to the volume control?
SDL_SysWMinfo info;
SDL_VERSION(&info.version);
if ( SDL_GetWMInfo(&info) ) {
/* We use the SDL GFX display (we're using the GFX window too after all) */
Display *dpy = info.info.x11.display;
unsigned long val = 1;
Atom atom_zoom = XInternAtom(dpy, "_HILDON_ZOOM_KEY_ATOM", 0);
info.info.x11.lock_func();
Window win = info.info.x11.window;
XUnmapWindow(dpy,win);
XChangeProperty (dpy,win,atom_zoom,XA_INTEGER,32,PropModeReplace,(unsigned
char *) &val,1);
XMapWindow(dpy,win);
info.info.x11.unlock_func();
}
Till
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Port of NeHe OpenGL tutorials
Hi, Am Freitag 09 April 2010 schrieb Ahmed Ammar: > Good stuff, but which GLES version are you porting to? GLES1 as this is IMHO closer to the GL version used in those lessons. > Also, I'd like to bring to your attention a very neat little wrapper > that tries to wrap most used GL2 functions to GLES2: > > http://code.google.com/p/gl-wes-v2/ My set of lessons is in no way limited to the NeHe tutorials, so if you want to contribute some simple and well-documented lesson, you are more than welcome. > I actually have got glgears working using this, although it's buggy > (can't get lighting to quite work) it makes porting GL2 to GLES2 pretty > simple. I haven't encountered any problems so far and the examples already include lighting, textures and other more advanced topics. > Just wanted to give my 2 cents. I am by no means a GL/GLES expert. In fact i am learning while doing this, so any contribution is welcome. Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Port of NeHe OpenGL tutorials
Hi, i've started to port the very nice OpenGL tutorial from http://nehe.gamedev.net/ to Maemo5/SDL_gles. The first 8 lessons are there ready to be tested from extras-devel. The project is called nehegles: http://maemo.org/packages/view/nehegles/ Hope this gives the usage of opengl on the n900 a little push ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3rd party rom images in maemo repository
Hi, Am Mittwoch 24 März 2010 schrieb Marcin Juszkiewicz: > Vice upstream tarball contains ROM images and thats why it boots directly. > Debian package has those files removed so user has to download them from > Internet. It doesn't matter if others also distribute these files. The only important question is whether maemo.org is allowed to distribute them. If they are alowed to do so since the files are out of copyright or since the vice team has a transferrable permission to do so it's fine. But this should imho then clearly be explained in the package description. On what legal basis does maemo.org distribute all those rom files? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
3rd party rom images in maemo repository
Hi, the arrival of the vice emulator in extras-devel and the fact that it boots directly into a x64 emulation without further interaction made me have a look for the rom images required for this. Interestingly, the vice package contains the full set of commordore rom images. When asking the author to rethink this he claimed that all those other emulators like speccy also come with original rom images. It seems that this shouldn't be happending and that someone at maemo.org should take a closer look at all those emulator packages to see whether they contain copyrighted rom dumps. It really doesn't make any sense to shout at people asking for game roms on t.m.o and calling them pirates while at the sa,e time distribute vintage computer roms yourself. Either you ban this or you allow maemo.org to be used to share all kinds of rom images. Everything else is hypocritical ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: promote libs in user/* cathegory
Hi, Am Dienstag 23 März 2010 schrieb Niels Breet: > But I still like zeemote-conf more than libzeemote-conf ;) Maybe ... but renaming something that has several dependencies and without an easy way to remove the conflicting earlier versions i prefer to just leave it the way it is. Thanks for fixing this, although Javier already removed zeemote support from DrNokSnes to avoid this issue to have an influence on its promotion. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Ask for removal of some packages from Extras Fremantle repository
> OK. Looks like you may have got me there. I guess this is why GPLv3 > clarifies this aspect a bit.> It hadn't dawned on me that maemo.org actually > complied with 3a and that there was actually no written offer. And you are satisfied that your contributions to this dicussion finally made the developer in question to refuse to continue his work? The important part is that you were able to mouth your demands and emphasise your understanding of your legal rights? Congratulations, mission accomplished! Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Ask for removal of some packages from Extras Fremantle repository
Hi, > > And why should you insist > Because the GPL says we can. The GPL also says that i can take your GPL app, modify it, even break it, reduce its functionality etc etc and replace the original version with my broken one. Still you wouldn't want me to do this even though it's perfectly legal. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
promote libs in user/* cathegory
Hi, the promotion interface refuses to promote my libzeemote-conf since it's a library which is in section user/* This imho doesn't make much sense since it's a) the config interface for my zeemote lib and why shouldn't a library have a user installable config tool and b) is of course a library like any other control panel plugin is. How can i get this promoted? And no, i don't want to rename everything just because the promotion interface doesn't like my naming. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
Hi, why should you have to continue to provide the sources once you removed the binaries? And why should you insist on uploading old versions to maemo respositories which a) just ignores the authors wishes and worse b) interferes with his work on establishing his own repository. Let him his freedom. Let him start his own repository and just see if he fails and ends up on those "warning, this repository is dangerous" lists or if he perhaps succeeds and ends as "the famous community driven repository that is more reliable and causes less anger and has cooler apps than the maemo repositories"? Who knows? Why not just letting him do this? Don't take all this so serious! Heck, it's only a cell phone we are talking about. It's not the end of the world if someone actually has fun messing with its possibilities. Till Am Montag 22 März 2010 schrieb Darren Long: > Presumably the source must continue to be available from the extras > repositories, even after the package binaries have been removed, assuming its > under the GPL, which e.g. Pygtkeditor is. > > I'd suggest not removing the binary packages from extras, on the grounds that > they don't have to be removed, and that maemo.org is free to distribute them > if we/they so wish. > > Furthermore, there is no reason why someone from maemo.org shouldn't push > source packages from other repositories into extras* to keep them up to date > and readily available in the maemo context. This is true for any upstream > free package in general, and equally true for any desirable package that > just so happens to have been pulled from extras on a whim. > > No disrespect to Benoit intended. > > Darren > > On 22 Mar 2010, at 15:22, Graham Cobb wrote: > > > On Monday 22 March 2010 14:30:00 Matan Ziv-Av wrote: > >> On Mon, 22 Mar 2010, Graham Cobb wrote: > >>> I just don't see how using your own repository is actually any **better** > >>> than just using extras-devel? > >> > >> There are a few problems with extras-devel: > >> > >> - There are way too many warnings all over the place (mailing list, > >> wiki, talk), so some users might be be reluctant to use this > >> repository. > > > > This will be true even more so for private repositories. If/when they > > become > > at all common, there will be warnings all over the place about not > > downloading things from private repositories. The biggest problem with > > private repositories is that there are no guarantees that the binary being > > installed bears any relationship to the sources offered (if any), or how > > securely the maintainer manages the repository, so people will start to > > worry > > about security/viruses/trojans. Plus a concern that "if this was > > legitimate, > > why wouldn't the developer use the community channels?". > > > > Please note that I am certainly **not** suggesting that you, or Benoit, are > > at > > all unreliable or incapable of managing a secure repository, but that > > people > > will worry about the risks at least as much as they do about extras-devel. > > > >> - Some of the warnings are true, so asking people to use this repositort > >> might expose them to unwanted updates. > > > > Yes. But using a private repository might expose them to updates where no > > one > > can even work out what happened when it breaks. > > > >> - autobuilder is too limited - currently you can't compile packages that > >> depend on versions in PR1.1. > > > > That is a short term problem which only affects a tiny number of packages. > > It > > is not a reason for removing something from extras-devel. > > > > If a similar problem occurs in the future and affects many packages, a > > solution will be implemented, just as it is being for PR1.2. > > > >> - You can't easily remove a package from extras-devel. (Or maybe at all? > >> I asked for a package to be removed two weeks ago. It is still there). > > > > Contact the debmaster (Jeremiah) by direct email. > > > >> - Using extras-devel might lock packages, preventing users that install > >> packages from this repository to later update them from another > >> repository. > > > > That is true. Although the user just has to remove the package and > > re-install > > it, instead. > > > >> That said, I prefer to have my packages available both in my repository > >> and in extras-devel, when it is possible. > > > > I also have private repositories, for my own testing and for other members > > of > > upstream projects (such as GPE) to do testing before I even push something > > into extras-devel. But that is not the same as publishing that location > > for > > end-users. > > > > Graham > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https
Re: Howto configure borderless 4:3 tv-out on n900?
Hi, thanks for your reply. I fiddled a little bit around with this. It's pretty easy to stretch the image vertically to full screen. You just need to set echo 640,480 > /sys/devices/platform/omapdss/overlay2/output_size and echo 42,30 > /sys/devices/platform/omapdss/overlay2/position The media player does the same. The problem is the horizontal stretch. You can't write to /sys/devices/platform/omapdss/overlay2/input_size and by checking what the media player does i found out that it actually changes this to 640x480 when playing a 4:3 video. Unfortunately the /sys interface doesn't allow to write these, so i'll have a look at the ioctls next. Till Am Freitag 19 März 2010 schrieb Frantisek Dufka: > I don't know if there is some high level api but a lot of things can be > done either via framebuffer ioctl or via changing stuff in > /sys/dev/ices/platform/omapdss/ see > > http://gitorious.org/linux-omap-dss2/linux/blobs/master/Documentation/arm/OMAP/DSS > > Having full PAL or NTSC with no translation/scaling would be good both > for games and video playback too. > > So far I have only succeeded to change the default 800x480 -> TV scaling > to be a bit better so it is no longer fuzzy due to extra downscaling. On > my TV I can get exactly 480 lines visible in PAL mode which makes > reading text much better. > http://talk.maemo.org/showthread.php?p=461660#post461660 > > > For NTSC output (640x480) it would be enough to render to part of the > screen and set the size and offset accordingly. For full PAL it would > need resizing framebuffer to get more lines (ioctl?). > > I wonder how OMAP3 display controller features (gfx,vid1,vid2 planes, > scaling, mirroring, rotation, tv-out) are mapped to Xv and other X APIs. > > Frantisek > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Howto configure borderless 4:3 tv-out on n900?
Hi, there seems to be an API to change the behaviour of the TV output on the n900. At least the media player uses it to e.g. display things with a different layout on the internal screen and the tv-out. I am asking this because i think it's a great thing to add to all those 640x480 (4:3) programs and especially emulators. The problem these have is that the have a black border left and right to accomodate for the 800x480 main screen and on tv-out they get another top and bottom border to display the entire internal display contents on the tv-out. The result is a 4:3 image on the 4:3 tv-out with black borders on all four sides and with pixels being lost. This isn't useful at all. I would be really cool if these applications could just request the tv.out to zoom/crop the 4:3 tv-output. That way most emulated games would run full screen and without any pixel loss. How can this be achieved? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Changing chinook support to archive mode
Hi, me too. All my projects are also built for chinook and i even still have an n800 running chinook for testing reasons. If chinook is officially be retired, i'll just flash my n800 to diablo and forget about chinook. I am fine with that. Till Am Dienstag 26 Januar 2010 schrieb Cornelius Hald: > On Mon, 2010-01-25 at 21:52 +0100, Niels Breet wrote: > > It has been quite a while since diablo became the successor of chinook. > > > > I think it is time to make the chinook repository read-only and close down > > the builder instance for it. > > I'm still building for all three platforms because I think there are > still a couple of people using Chinook out there. I know at least one > active tmo member who is always testing Conboy on Chinook. > > > This would let us concentrate on improving the features for the platforms > > that are actually in use. > > Why not just keep it running? Does it create so much extra work? Maybe > we could look at some stats, like how many Chinook packages have been > downloaded within the last 30 days? > > Cheers! > Conny > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem in compiling
Hi, ok. If you know a package is installed you can always try to figure out what pkg-config thinks how its named: [sbox-FREMANTLE_ARMEL: ~] > pkg-config --list-all| grep alarm alarm alarm - alarmd client library So it seems pkg-config thinks the package is just named "alarm". Thus you might try: gcc alarm.c `pkg-config alarm --cflags --libs` -o alarm Till Am Dienstag 26 Januar 2010 schrieb gaurav sinha: > Thanks for your concern. > I tried what you said but again it is giving the same error. > > [sbox-FREMANTLE_X86: ~] > apt-get install libalarm-dev > Reading package lists... Done > Building dependency tree... Done > libalarm-dev is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > [sbox-FREMANTLE_X86: ~] > gcc alarm.c `pkg-config libalarm-dev --cflags > --libs` -o alarm > Package libalarm-dev was not found in the pkg-config search path. > Perhaps you should add the directory containing `libalarm-dev.pc' > to the PKG_CONFIG_PATH environment variable > No package 'libalarm-dev' found > alarm.c:5:32: error: alarmd/alarm_event.h: No such file or directory > alarm.c: In function 'main': > alarm.c:11: error: 'alarm_event_t' undeclared (first use in this function) > ... > .. > > On Wed, Jan 27, 2010 at 1:07 AM, Till Harbaum / Lists > wrote: > > > Hi, > > > > Am Dienstag 26 Januar 2010 schrieb gaurav sinha: > > > I am not able to compile source code ( > > ... > > > No package 'libalarm-dev' found > > ... > > > > What about installing the missing package? Try: > > > > apt-get install libalarm-dev > > > > > alarm.c:5:32: error: alarmd/alarm_event.h: No such file or directory > > > alarm.c: In function 'main': > > > alarm.c:11: error: 'alarm_event_t' undeclared (first use in this > > function) > > > alarm.c:11: error: (Each undeclared identifier is reported only once > > > alarm.c:11: error: for each function it appears in.) > > > alarm.c:11: error: expected ';' before 'event' > > > alarm.c:12: error: 'cookie_t' undeclared (first use in this function) > > > alarm.c:12: error: expected ';' before 'cookie' > > > alarm.c:15: error: 'event' undeclared (first use in this function) > > > alarm.c:27: error: 'cookie' undeclared (first use in this function) > > > [sbox-FREMANTLE_X86: ~] > > > > > > > > > > ... > > > please help!!! > > > > > > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem in compiling
Hi, Am Dienstag 26 Januar 2010 schrieb gaurav sinha: > I am not able to compile source code ( ... > No package 'libalarm-dev' found ... What about installing the missing package? Try: apt-get install libalarm-dev > alarm.c:5:32: error: alarmd/alarm_event.h: No such file or directory > alarm.c: In function 'main': > alarm.c:11: error: 'alarm_event_t' undeclared (first use in this function) > alarm.c:11: error: (Each undeclared identifier is reported only once > alarm.c:11: error: for each function it appears in.) > alarm.c:11: error: expected ';' before 'event' > alarm.c:12: error: 'cookie_t' undeclared (first use in this function) > alarm.c:12: error: expected ';' before 'cookie' > alarm.c:15: error: 'event' undeclared (first use in this function) > alarm.c:27: error: 'cookie' undeclared (first use in this function) > [sbox-FREMANTLE_X86: ~] > > > > ... > please help!!! > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Where have the diablo/chinook promoters gone?
This gives me a "page not found": https://garage.maemo.org/promoter/chinook Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo.org incorrectly reports broken dependency
Hi, i can't promote maep 1.3 into testing because maemo.org claims that it has broken dependencies: http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/maep/1.3/ This is 1) not true as it installs fine on the real thing 2) is really strange since the autobuilder created that version How do we solve this? Do i just have to upload the same source code again as this was a glitch in the autobuilder? Or will this be fixed in maemo.org side? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Extras-devel doesn't update?
Hi, i released maep 1.3 today and according to all logs and http://maemo.org/packages/view/maep/ it should have arrived in extras-devel by now. Still my n900 doesn't see it Why? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SVN moved permanently?
Hi, Am Samstag 16 Januar 2010 schrieb koos vriezen: > svn switch --relocate https://garage.maemo.org/svn/kmplayer > https://vcs.maemo.org/svn/kmplayer > > (but I've made google as my friend :) Agreed, every developer might take the time to google this. But things are much easier (and less error prone) if the one in charge of this server change would have sent a short email to this list telling people to expect these issues and how this command solves them. Thanks, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SVN moved permanently?
Hi, it would imho be really a good idea if the maemo.org maintainers would document such changes and just write down a few lines of text describing what will change and how the average developer is supposed to cope with this. This e.g. seems not to work: $svn relocate Unknown command: 'relocate' Type 'svn help' for usage. Till Am Freitag 15 Januar 2010 schrieb Henning Heinold: > Hi, > > there is an svn relocate command which should do fine. > > Bye Henning > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
SVN moved permanently?
Hi, $ svn up svn: Repository moved permanently to 'https://vcs.maemo.org/svn/maep'; please relocate Is there anything _i_ have to do about this or will this be fixed on server side? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Broken state of repositories
Hi, Am Freitag 15 Januar 2010 schrieb Marcin Juszkiewicz: > Other thing: *-dbg packages in extras-devel. OK, this is repo for developers > rather then users but can't we move such packages into "debug" section where That's the point: This repository _is_ for developers. You have a repository that fixes all the things you complain about: It's named "extras". Or if you want a little more adventure then use extras-testing. If you think there's a real need for end users to use extras-devel because of some package that you consider end user ready, then get in contact with its author and ask why that package didn't make it yet into extras-testing or extras, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, i just realized that we are talking about completely different things when we say "geotagged". I am relating to GPS positions. You seem to relate to place names. I just learned that the n900 does not write GPS tags. Correct? Unfortunately that completely spoils the idea to use maep to display these. Converting GPS positions into place names and back to coordinates will likely cause most images to show up pretty far from their real location and even worse will make them all show up at the same place. Is there a way to enable real GPS tagging? Is there any reason why this isn't happending? It's so obvious that just i didn't expect this not to be there. Till Am Montag 11 Januar 2010 schrieb Ivan Frade: > Hi, > > El vie, 08-01-2010 a las 20:45 +0100, ext Till Harbaum / Lists escribió: > > Hi, > > > > Am Freitag 08 Januar 2010 schrieb Ivan Frade: > > > > see it when i arrive there). This will be supported in tracker 0.7 > > > (ready to play with on desktop), but not in 0.6/fremantle. > > Using tracker 0.6 limited to images is a start. Do you have example > > code somewhere? I have never worked with tracker before. > > We have some (basic) documentation here: > http://live.gnome.org/Tracker/Documentation/RDF-Query > > Tracker is a daemon visible in DBus. In python, connect to the daemon > directly (an example in my own pet-project [1]). In C, use > libtracker-client (some examples in MAFW's tracker backend). > > There should be some libtracker-client gtk-doc documentation, but it > looks like library.gnome.org only contains the last unstable version > (0.7). This is useless for you, the API in 0.7 is _completely_ different > from 0.6 API. Don't get confused with that. > > The properties you can use in your queries are defined here: > http://git.gnome.org/browse/tracker/tree/data/services?h=tracker-0.6 > > You can also monitor dbus while using the image-viewer to see some > queries flying. > > Regards, > > Ivan > > [1] > https://garage.maemo.org/plugins/ggit/browse.php/?p=mussorgsky;a=blob;f=src/tracker_backend.py;h=e956f38668066423fa9538a1cb69a4082f776fa8;hb=9d71d07b572bdf50114484b28a0e188d742fcdfc > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification creates link-loop
Hi, many apps handle the --datadir option correctly and can thus move bulk data automatically into /opt. But --prefix=/opt would also install the executable, the icons and the .desktop file there. Unfortunately Nokia is not supporting files to go there and you have to create links back to /usr. --prefix doesn't do that for you. Till Am Dienstag 12 Januar 2010 schrieb Martin Grimme: > Hi, > > Is there not a way for your app to directly install it into /opt > without all that optification black magic? > ./configure --prefix=/opt/conboy > perhaps? > > > Martin > > > 2010/1/12, Jeff Moe : > > On Tuesday 12 January 2010 10:56:16 you wrote: > >> Jeff Moe wrote: > >> > https://bugs.maemo.org/show_bug.cgi?id=7707 > >> > >> That´s exactly it Jeff. Thanks for the hint! > >> The questions are now: Is there a known work-around? > > > > Either optify "by hand" or turn off optification until the bug gets fixed: > > echo none > debian/optify > > > >> Will it get fixed > >> in maemo-optify soon? > > > > Nokia doesn't comment about future plans or somesuch. ;) That said, I'm > > surprised it's not fixed already as they seem to be close to automatically > > optifying by default everything submitted to the builder. > > > > -Jeff > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: is 44-1 officially going to be available as an image ?
Hi, Am Dienstag 12 Januar 2010 schrieb Mikko Vartiainen: > > Any idea why my n900 doesn't see the update? > > Have you accidentally removed SSU metapackage (mp-fremantle-generic-pr)? > Yes, i did. I once removed those pre-installed games using apt-get. And since the metapackage had a dependency on these, it was also removed. Fortunately a simple "apt-get install mp-fremantle-generic-pr" gave me a successful update. But i assume this is pure luck as apt-get doesn't do all the magic the application installer does to make sure the installation succeeds. The "correct" solution probably is to install the old version of this package using apt-get and then let the app installer do the update. Thanks, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debian/optify not sufficient
Hi, Am Dienstag 12 Januar 2010 schrieb Marius Vollmer: > ext Till Harbaum / Lists writes: > > > i just added a debian/optify file containing nothing but the word > > auto to Maep 1.1. Unfortunately the resulting deb package still > > has the binary in /usr/bin > > > > Why? > > Could you show a complete transcript of the build? > Never mind. I have been told that auto optification is either all or nothing. So i'll manually optify it a little more. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: User-specific files for maemo packages
Hi, Am Montag 11 Januar 2010 schrieb ibrahim: > I wonder how can I put some user-specific files on the filesystem that > can't get removed when my application package is uninstalled. Don't create the directory through the debian package, but let the application create the directory when there's a need (e.g. just when you want to store your app specific files). Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: is 44-1 officially going to be available as an image ?
Hi, Am Montag 11 Januar 2010 schrieb daniel wilms: > just flash with 42-11 and then update. My device just doesn't see the update. The only difference to my wifes n900 which did see the update seems to be that my device has the nokia repository set to: https://downloads.maemo.nokia.com/fremantle/mr0 while hers (now) shows: https://downloads.maemo.nokia.com/fremantle/ssu/mr0 I tried changing this manually, but can't find the settings for this, neither in /etc/hildon-application-manager nor in gconf (the stuff in /etc/apt is only created by the app manager and cannot be changed permanently). Any idea why my n900 doesn't see the update? Where can i change the settings for the system repository? Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Attn map application developers: common cache for maps
Hi, you want to store hundreds of megabytes of map data in ram ... cool ... And what's the advantage of a database if you want to store files? Till Am Montag 11 Januar 2010 schrieb steven gu: > Hi: > > Have you ever considered using two types of caches? Memory cache(maybe shared > memory) and persistent cache(sqlite?). > > Best regards, > Asongala > > -- > http://code.google.com/p/xinfomap/ > http://code.google.com/p/xinfoqr/ > > > > > Hi all, > >I'd like to propose a standard location to store cached map tiles > > (from openstreetmaps, google, or whichever), so to avoid re-downloading > > the same tiles when a user is using several applications which store > > their data in different directories. > > > > I'm working on maemo-mapper at the moment, and I know there are other > > applications (eCoach for instance) that are using map data. We could > > save user's bandwidth, time and flash space if we put the map tiles in > > the same place. > > > > I would suggest using > > ~/MyDocs/.maps/.png > > > > Where can be "google.com", "openstreetmap.org" or others, and > > is "street", "satellite", "hybrid", etc. > > > > Does anyone have a better proposal? > > > > Any map application developers here, interested in sharing maps with > > maemo-mapper? > > > > Ciao, > >Alberto > > > > -- > > http://www.mardy.it <- geek in un lingua international! > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
Hi, can i force it to optify the remaining stuff, anyway? I consider optification to be so ugly that i rather have the script doing something nasty than spending even more time with it myself. Till Am Samstag 09 Januar 2010 schrieb Andrew Flegg: > On Sat, Jan 9, 2010 at 08:49, Till Harbaum / Lists wrote: > > > > hmm, i added a debian/optify with content "auto" to exactly that version. > > But the resulting binary is still in /usr/bin. I am confused ... > > "auto" will only optify the package if certain criteria are met. One > of these (the key one in fact) is whether it's already optified. This > is important for when "auto" becomes the default. > > Since you've got stuff in /opt/maep, maemo-optify-deb will not do any > further optification, as it considers that you're aware of > optification and done it yourself. > > HTH, > > Andrew > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
debian/optify not sufficient
Hi, i just added a debian/optify file containing nothing but the word auto to Maep 1.1. Unfortunately the resulting deb package still has the binary in /usr/bin Why? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
Hi, hmm, i added a debian/optify with content "auto" to exactly that version. But the resulting binary is still in /usr/bin. I am confused ... Till Am Samstag 09 Januar 2010 schrieb Jeff Moe: > On Friday 08 January 2010 17:01:10 Till Harbaum / Lists wrote: > > Hi, > > > > maep 1.1 is currently in the autobuilder and is supposed to store > > tiles where you suggested. It is supposed to ask the user whether > > he wants to move the existing cache etc ... > > > > Please give it a try and check that you can live with the result. > > WORKSFORME. The tile maps appear to have moved. I just did a quick test of > disconnecting net and then looking at previous places and they were there and > also switching from Hybrid to Google maps, etc. I didn't dig deeper, but it > appears to have worked. > > Thanks for Maep, it's my favorite mapping program. :) > > -Jeff > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Unified map tile storage
Hi, maep 1.1 is currently in the autobuilder and is supposed to store tiles where you suggested. It is supposed to ask the user whether he wants to move the existing cache etc ... Please give it a try and check that you can live with the result. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, Am Freitag 08 Januar 2010 schrieb Ivan Frade: > About other media types... there is no other format containing > location, so tracker cannot fill that information by itself. In this web site you can download wav files which claim to be geotagged: http://www.freesound.org/samplesViewSingle.php?id=73423 That's why i thought the maemo-recorder could do the same. > see it when i arrive there). This will be supported in tracker 0.7 > (ready to play with on desktop), but not in 0.6/fremantle. Using tracker 0.6 limited to images is a start. Do you have example code somewhere? I have never worked with tracker before. > 3) Scanning and reading files is not CPU expensive, but needs a lot of > IO, and IO is a very precious resource. Whatever the limit is: You don't want to do this in every single app. Reards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, Am Freitag 08 Januar 2010 schrieb Michael Cronenworth: > GPS data is stored in tracker for images only. Till wants GPS data for > *all* file types. If the tracker really already has basic geotagging support, then i think it's the only acceptable solution to use it, even if this is currently limited to images only. This sounds like a classic chicken/egg problem and as long as only the image viewer supports geotagging, noone will bother to extend the tracker for other formats. So if tracker can provide geotagging info i'd be more than willing to use that. Perhaps e.g. the maemo-recorder guys can be convinced to tag their files and this might in turn cause someone to extend the tracker functionality to support geotags in sound files ... I really REALLY think tracker is the only useful way to deal with geotags especially in a mobile device where indexing may really be expensive with respect to CPU power and battery. What's the tracker guru's opinion? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, Am Donnerstag 07 Januar 2010 schrieb Michael Cronenworth: > > How do i access geotags? > With libexif. GPS coordinates are in the EXIF data. This only works for jpeg images which are only a fraction of media files stored on an n900. I was fearing to get some answer like this. This has so many disadvantages: - We'll have to scan all files in every geotag aware app - This consumes much CPU power - This takes a very, VERY long time - This does not work with MP3/WAV/PNG/GIF/AVI/... - This information can hardly be shared between different apps - My app has to cache/store this information for all media files to not be forced to re-scan everything everytime it's being started I am afraid this will mean that such a project doesn't make much sense. Thanks, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, thank for you for your reply. Am Donnerstag 07 Januar 2010 schrieb Michael Cronenworth: > > - This consumes much CPU power > Reading a file is hardly CPU intensive. Reading thousands of files is. I really don't have much media stored on my n900, but it's already 400 mp3 files, 150 jpegs and 40 avi videos. Scanning them for tags aready would take a long time and even worse would consume lots of CPU (and thus battery) power. > > - This takes a very, VERY long time > Not on an SSD unless you have billions of files. Reading several thousand media files does not take long? You'll have to scan all oif them, even if only a fraction of them actually contains geotags as you don't know which the ones with geotags are before you actually search for them. > > - This does not work with MP3/WAV/PNG/GIF/AVI/... > Quite right. Why do you expect GPS information to be available for these > files? Who told you to expect GPS data from those file types? Why should i assume that i can savely ignore them if they all may actually contain geotags? Why should i be sure that e.g. maemo-recorder nor any other app puts geotags into the wav files it stores? > > - This information can hardly be shared between different apps > The standard for JPEG type files is to use EXIF for any and all > metadata. Any app should and can support reading EXIF. But then every single app has to scan every single file. That's awful. > I think you need to re-think what your goal is. That's sad as it really limits the usage of geotags. The "right" solution would sure be to let tracker handle this as it's the purpose of tracker to index the disk for media files and to provide meta information to all apps interested in this. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to access geotag information?
Hi, i am planning to add a feature to Maep so that it displays small thumbnails of geotagged media data. How do i access geotags? I suppose the correct way to access any media files is to go via tracker. Are there any examples to request geoinformation from tracker? A little googling reveals many pages saying that "tracker doesn't index geotags". Is this true? What is the correct way to get geotags of all media stored on the device? It sure doesn't make much sense to ask tracker for a list of all media and than try to extract geotags from them. This would take forever on a big media collection. Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: > What's the advantage in delaying the optification? It is soo easy. A The disadvantages: Another round of testing on my side for all three plattforms. Making sure that all features in that version are usable, so i can't just take the current svn which includes half-done features. Loosing existing thumbs-up. The users won't be able to start the optified binary from the command line anymore. Etc etc ... > whopping 4 bytes or so. It sounds like your app shouldn't have made it to > extras in the first place if it wasn't optified. It _is_ optified and uses ~280k of rootfs space for the binary itself. > Just optify and let this die finally. Will happen with the next release once all features currently pending are done. Until then the broken version stays in extras (e.g. crashes if you try to view the "relations" of a "relation" and the WMS feature is barely usable due to an offset error). Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: > Does this, perchance, have anything to do with what you are talking about? > http://maemo.org/packages/package_instance/view/fremantle_extras- > testing_free_armel/osm2go/0.8.1-maemo1 Sure > I must say he annoyed me to at first, but make my silly package better for in > in the end. Seems if you just freaking optified your binary all these threads > could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. I am annoyed by the fact that my bug fixes are delayed for something the version already in extras also has. Where's the advantage in delaying the update? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Gary Birkett: > the voice of the commons is generally to be listened to. Listening to them is fine. > we put our apps into the community, > our apps are going on their devices, > why should we have more say than them? I don't propose that we need to have more to say then them. I just ask certain people to give their vote. This is how all elections work: You ask those people to vote who you think have the right understanding. I am asking developers since i trust them more than someone doing those tests to get enough karma to get the next-gen device for free. > a cabal of rebels overruling usually valid issues undermines the process for > everyone. Why are developers rebels? I am not asking those people to give a thumbs up for just everything. I ask them to reconsider and override the vote of someone who perhaps doesn't have enough knowledge of the things he's judging upon. > i have not updated any apps since finding out I also have to handle > optification and other issues. > i'm not upset at the mechanism though. I am not sure i understand that. You "gave up". Is that right? If this i fine for you: Good. But what if you could actually convince these lists members that indeed your app is a win and that e.g. in your case optification isn't useful? Why not giving you a place/group to explain your technical reasoning behind your work? > > What do you think? I really think it's wrong that testers can stop > > bad developers, but that there's no way for developers to stop > > bad testers. > > > > that sounds like a freudian slip, its right that testers can stop bad > developers. Perhaps i wasn't clear. I meant: It's good that there's a mechanism to stop bad developers. But it's bad that you can't stop bad testers. > till, I know you are miffed about this process, we all have growing pains > with the new steps, but we want all our users to have the best experience > possible So do i. Preventing bug-fixes from reaching extras due to issues the version already in extras also has is e.g. useless. You gain nothing if there already is a version in extras which has this "flaw" that's causing the update to be delayed. I am willing to learn: What's the disadvantage of uploading a new version that isn't perfect but better than the previous version? Once a program is in extras the rules what's good and bad just change. Everything better than the previous version should be "good". Or what am i missing? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Proposal: Karma-Whores protection mailing list
Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Freitag 01 Januar 2010 schrieb Alberto Mardegan: > directory exists (and is a regular dir, not a symlink) and if so copies > all the tiles into the new location, and then removes the old dir and > makes it a symbolic link to the new location. Yes, that what i also came up with after some thinking. The only issue: This may take some time. I e.g. have ~150MB in that directory. The user may think the installation hangs if i move that much data. So some dialog has to be presented to the user. Ciao, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: > This is my goal, but please move them in the 32GB storage. :-) Oh, i see what you mean. Urgh ... that's a tricky one as moving them for one app will break the other one. Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: > Speaking of which, it would be nice if you instructed osmgpsmap to store > the tiles under /home/user/MyDocs/.maps/ so that they could be shared > with maemo-mapper (I probably need to modify it a bit so that the > repository names are the same that osmgpsmap uses). Uhm, maemo mapper has only recently been ported to maemo5. When i came up with my naming scheme i was the only one storing map tiles that way. Changing things now would mean that all of my apps have to cleanup the old paths and convert the to the new scheme while at the same time making sure that they don't affect maemo mapper etc etc ... With maemo mapper being in a such early state of development i am hesitating to adopt to its rules. And finally: Since when does maemo mapper store plain tiles at all?? Doesn't it store everything in databases (even in varying sqlite or gnudb format)? > Or please let me know if you have a better proposal. I am definitely willing to work on this. But today maemo mapper seems to be far from even alpha quality, so i am not sure if i want to change my apps already being in extras to deal with the map tiles repositories of a pre-beta version from extras-devel. What about making maemo mapper deal with my repositories? I very likely by now have the bigger installed user base and thus have to expect more trouble during such a transition. Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Jeff Moe: > You should do so, so your users don't brick their phones. It's soo easy > to > put everything in /opt. I agree the symlinking madness is a bit messy, but it > workz and it's what we are stuck with until we have 2G NANDs. In fact i just thought that i can put the binary in opt and reference it directly from the .desktop file without putting a symlink into /usr/bin I'll do that in the next release (although i don't have a clue how you expect my program to brick a phone by not doing so). Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Andrew Flegg > * you maintain both libgoocanvas3 and osm2go Still this would require additional work i'd like to avoid. > * neither are optified (according to the comments) Osm2go is of course optified, otherwise it wouldn't already be in extras. Just the stuff the system needs symlinks for is still in rootfs as i really think this excessive symlinking is ugly as hell. > * I *imagine* there aren't lots of other apps depending on > libgoocanvas3 which have been let through QA Xournal? > ...this would seem to fall on to your shoulders. The STRONG > recommendation is that EVERYTHING is optified, and getting pedantic > about the numbers when you control both halves of the application > stack seems a little churlish. After all, someone wanting to be > difficult could split their app into 500 2KB packages which depend on > each other :-) Then why do you talk about a 500kB limit if you in fact want _everything_ in /opt? What's the point of giving hard numbers and then stating that you want something different? > Now, on to solving the problem, have you tried putting "auto" in > debian/optify? If so, did both packages continue to work after being > auto-optified by the builder (or maemo-build-deb in Scratchbox, if you > prefer). Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. There is a rule, i am following it and that's it. If you don't like the rule, then change it. If you think my interpretation of the rule is valid but not what it intends to say, then re-phrase the rule to become clear. If you want to do neither: Accept my interpretation. > The intention is that they *should* (which is why 'auto' will become > the default at some point in the future). That's the moment where i'll have to deal with it. Not before. As i said above: I think the current 500k limit per package is just fine, so for me this is just an unnecessary hurdle. > Hope that helps, > > Andrew > Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to change button shape?
Hi, Am Dienstag 29 Dezember 2009 schrieb Cornelius Hald: > The theming is defined here: /usr/share/themes/default/gtk-2.0/gtkrc > If you look for example for "fremantle-button-group-box" you will find a > style which defines those toggle buttons which are only rounded at the > outer left and right button. > > There is the GtkStyle API with which you can apply a defined style to a > specific widget. It's rather cumbersome, but it might work for you. If > you're still interested, I can dig up some code where I used this API. Thanks, but i won't need it if it gets complicated. I was interested in using this for buttons used as a replacement for gtknotebook tabs in fremantle. But the current toggle buttons already look quite nice for this purpose, so there's no need to make things more complex. Thanks again, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Eero Tamminen: > Where this 500kB figure for these packages come from? As long as there's no indication whether the limit itself is meant to be interpreted as logical or physical memory space there's imho no point of discussing what this guy actually measured. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi,
it's likely wait too late for such a question, but why doesn't just /opt/bin,
/opt/share etc exist with the system looking into those paths as well?
Noone would have to care about optification then, no symlinks would
be required and most packages could just be optified by "configure
--prefix=/opt".
I must be missing a very obvious thing that makes the current solution
better/nicer/whatever.
Till
Am Dienstag 29 Dezember 2009 schrieb Michael Cronenworth:
> Jeff Moe on 12/29/2009 08:20 AM wrote:
> > I don't understand why maemo-optify doesn't just move*everything* to /opt,
> > including files under 2k etc. What advantage does it give to not have them
> > in
> > /opt? For instance, I ran into this problem with asterisk where it had many
> > small sound files which still put 600k on the NAND.
> >
> > -} elsif ($size>= 2048) {
> > +} elsif ($size>= 0) {
>
> Submit a patch to maemo-optify[1]. This is a must. Only kernel/Nokia
> libraries should be on the rootfs. With so little space, there is no
> reason for any end-user or commercial generated content to be on the rootfs.
>
> [1] http://gitorious.org/+maemo-af-developers
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, the page you are referring to says: "The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. " It does not say that the _sum_ of all dependencies has to be below 500k. This rule that the sum of all components also has to stay below a certain limit is new. Osm2go is below 500k and so is the goocanvas it depends on. Now this guy is talking about the fact that the sum is over 500k. Till Am Dienstag 29 Dezember 2009 schrieb Andre Klapper: > Am Dienstag, den 29.12.2009, 13:18 +0100 schrieb Till Harbaum / Lists: > > http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 > Error 404: Page could not be found. Probably > https://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/osm2go/0.8.1-maemo1/ > > > Guys, i really hate the fact that you come up with new rules every > > three days. > > Who exactly is "you" in your sentence? > > According to the ChangeLog, 500k has been listed at > http://wiki.maemo.org/Extras-testing/QA_Checklist since Oct 22nd, 2009. > > Maybe you meant "two months" instead of "three days"? > > andre ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, sorry, the link was truncated. I am talking about: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138713 Additional info: There already is a version in extras that is exceeding these new limits. The new version fixes some bugs. So the new version gives no disadvantage over the version currently in extras. Delaying it just prevents the bug fixes to reach the end users. Till Am Dienstag 29 Dezember 2009 schrieb Till Harbaum / Lists: > Hi, > > i have just been instructed to reduce the size of osm2go _incl._ its > depending libraries to under 500k: > > http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 > > Guys, i really hate the fact that you come up with new rules every three > days. I have already had complains about "doesn't look nice enough", "won't > run on maemo6" and now this. > > Please either > > a) make the all-libs-together-have-to-stay-under-500k an explicit rule for > extras and i'll consider following that rule, or > > b) just delete that thumbs-down if it's not appropriate and make clear that > it's not required that all components together stay under 500k > > Till > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New optification issues in extras-testing
Hi, i have just been instructed to reduce the size of osm2go _incl._ its depending libraries to under 500k: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Guys, i really hate the fact that you come up with new rules every three days. I have already had complains about "doesn't look nice enough", "won't run on maemo6" and now this. Please either a) make the all-libs-together-have-to-stay-under-500k an explicit rule for extras and i'll consider following that rule, or b) just delete that thumbs-down if it's not appropriate and make clear that it's not required that all components together stay under 500k Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to change button shape?
Hi, hildon buttons can change their shape and their corners aren't always round. One example are those three toggle buttons in the top row of the calender menu. This particular type of reshape seems to happen magically once those buttons are inside a hbox. But there's also the popup keyboard with the "abc" button which doesn't show the round corners at the bottom. I have a similar setup and also want those bottom corners to not be round. How is this accomplished? How can i influence the shape of such buttons explicitely? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why is always one textview item selected in HILDON_UI_MODE_EDIT?
Hi, that's pretty exact also my solution. In the first change event i receive i just deselect everything and don't fo any further processing. Till Am Freitag 18 Dezember 2009 schrieb Marc Ordinas i Llopis: > Hi, > > On 18/12/09 12:45, Till Harbaum wrote: > > Hi, > > > > Anybody else facing this problem? How can i deselect everything in a > > treeview in > > state HILDON_UI_MODE_EDIT? > > > > > I was having the same problem with a GtkIconView and resorted to calling > gtk_icon_view_unselect_all after showing the widget. I still get the > selected events, though. > > Regards, > marcoil > > Regards, > >Till > > > > > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why is always one textview item selected in HILDON_UI_MODE_EDIT?
Hi, Am Freitag 18 Dezember 2009 schrieb Alberto Garcia: > Doesn't that work? That's what GTK_SELECTION_BROWSE is for. It's GTK_SELECTION_SINGLE what i want. But single behaves like browse on Maemo5 in a pannable area. > See hildon-touch-selector-normal-mode-example.c That example is not using edit mode but normal mode. Normal mode doesn't work for me as it immediately de-select everything you select. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Why is always one textview item selected in HILDON_UI_MODE_EDIT?
Hi, i have a simple treeview inside a pannable area. What i want to achieve is basically simple: I want the user to be able to select one item and that item should stay selected until the user selects a different item. Initially nothing should be selected. Exactly this is the standard behaviour in gtk. In hildon, however i need to enable edit mode to make something stay selected after the user clicked on it. There's a problem with this: Initially the first item is automatically selected by some magic in this mode. I even immediately get a "changed" event from the selection once the widget is being created. How do i prevent this? Even explicitely unselecting everything using gtk_tree_selection_unselect_all() doesn't help. The first item stays selected. This is bad since i was something to happen once the user selects an item. The user might thus not be aware that he also needs to click onto the already selected first item if he wants that first item to act. Anybody else facing this problem? How can i deselect everything in a treeview in state HILDON_UI_MODE_EDIT? Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to make python2.5 default in scratchbox?
Hi, i am trying to port some software that requires scons at build time and which in turn needs python2.5. There is a python 2.5 in the repository, but scratchbox comes with its own python 2.3. Now the question: How do i make python2.5 the default? And this needs to be in a way that also works with the autobuilder. I am trying to port the latest version of widelands to maemo5. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing Map-based apps for N900
Hi, Am Mittwoch 09 Dezember 2009 schrieb Paul Drummond: > Thanks for all the help. I am trying maemo-mapper now and I am also looking > at various QtWebKit examples that use google maps. I just put "Maep" in maemo-extras which is a fast and easy to use map widget which can be integrated into any gtk or hildon application. The maep program itself is a very simple example and just displays the map and interfaces it to the GPS. Two of my other projects (gpxview and osm2go) use this very same map. Maep runs on OS2008 to Maemo5 and also on plain gtk (which is what i most of the time use for development). Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How's using embedded html rendering in fremantle?
Hi, Am Montag 07 Dezember 2009 schrieb oleg.romas...@nokia.com: > Mail is using gtkhtml for embedding. Will take a look at this, but usually the nokia apps use heavily modified custom version of most widgets and don't stick to the basic ones. > I can only suggest to use browser embedding EAL - see tutorial application > also it is possible to use mozilla embedding directly or gtkmozembed. Ok ,thanks, will also have a look at this. > In future we can provide API for building web application with responsive-UI > widget (current browser rendering widget) This usually means that it will come in some distant future and also won't work with existing/previous devices. So to summarize: There's no preferred way to embed html and every app in fremantle current has its own solutioin (which is also visible from the number of html rendering engines in the repositories an even worse from the number of such engines the typical n900 will have installed ... Hmm, i'd really like to see nokia giving some guidance here so the average developer does not have to cope with various different solutions. Thanks, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How's using embedded html rendering in fremantle?
Hi, i'd really like to get in touch with someone who's embedding rendered html in his application. I am fighting with this now since the first days of fremantle and still things don't work as they did in diablo. I am using gtkhtml. This doesn't work well when being put inside a pannable area, nor does it work nicely when using its own "finger panning". Also selection seems to be totally broken in fremantle and even the version using a scrollable window (which works fine in diablo) doesn't work in fremantle. I really would like to get in touch with other people dealing with html rendering in their apps and to see how they solved issues like smooth finger scrolling and text selection. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SVN problems on garage
Hi, Am Montag 23 November 2009 schrieb Andrea Grandi: > what version of svn client do you have? Where do you chek your sources > from, using the svn client provided with scratchbox or using your > distro one? $ svn --version svn, Version 1.5.4 (r33841) from Ubuntu 9.04, not the scratchbox one. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SVN problems on garage
Hi, no problems here, can check in changes and new files as usual. Till Am Montag 23 November 2009 schrieb Cornelius Hald: > Does no one else have troubles with SVN on garage? I can't check in new > files into conboy and not into hildon-extras. Maybe I have to check my > svn installation?! > > Could someone please try to check in a new file into SVN and tell me if > it works. That would be really nice :) > > Thanks! > Conny > > > On Sat, 2009-11-21 at 03:56 +0100, Cornelius Hald wrote: > > Hi, > > > > I don't know if the problem is with me or the server. When I try to > > commit something I get the following error: > > > > Adding conboy/src/he-fullscreen-button.c > > svn: Commit failed (details follow): > > svn: Repository moved temporarily to > > 'https://garage.maemo.org/svn/conboy/! > > svn/wrk/5fe2da81-fede-4ca0-877e-f59381bea223/trunk/conboy/src/he-fullscreen-button.c'; > > please relocate > > > > I removed my working copy, did a clean checked out, added two files and > > tried to check in again. Still the same problem. > > > > Hopefully someone can help me :) > > > > Thanks! > > Conny > > > > > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras Testing to Extras, again...
Hi, ok, here's my proposal: Let the system send out emails to all testers that voted thumbs down once a new version is released and remind them to verify if the flaws they've complained about are gone. Or send even an email to all testers of the previous version to ask them to re-test. I must admit that i also don't re-check software i've voted for since it's not that easy to keep an overview on updated packages. Such an email would imho be acceptible as you earn karma with this. Perhaps you can even ask not be notified of new versions, but also not get any karma for testing then. This should also saisfy privacy-concerned testers. Till Am Freitag 20 November 2009 schrieb Brent Chiodo: > I'm also in roughly the same position as Aniello with my application > TouchSearch [1]. I have a new version ready to be released but will > not throw away seven thumbs up to do it... > > I wish I could just upload it to Extras now; it's a simple Desktop > Widget, I think seven people saying it is working fine is enough! > > [1] > http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/touchsearch/1.2-2/ > > > On 11/19/09, Aniello Del Sorbo wrote: > > So... > > > > I am sure I missed something... but what actions were taken to address > > this issue? > > I do have Xournal pacakge 20 for more than 10 days with 6 thumbs up > > out of 10 (i.e. more than 50% of people voted OK). > > > > I want to promote it to Extras. > > And I don't want to depend on others. > > > > I REALLY would like to see a Promote to Extras earlier in the process. > > It's up to me to wait enough time so that people can test it. > > Again, what I think it's missing is something to vote after the > > packages has been promoted to Extras so that the bad ones can > > be pulled out. > > > > If the fear is for malicious applications, then there's no way we can > > prevent those from going to Extras no matter how many days > > it's been in Testing. > > (a timer comes to mind). > > > > Anyway... actions should be taken and asap. > > Please. > > > > -- > > anidel > > Sent from London, Eng, United Kingdom > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging a bookmark?
Hi, as long as the app manager is a flat list of things i'd oppose to this. It's already a problem to finger scroll to the list of gcompris-packages. Having to also scroll though a list of bookmarks would make things worse. Till Am Freitag 20 November 2009 schrieb Thomas Waelti: > Hello list > > Some of you might have seen my Google Maps "webapplication" called maeMaps > (http://tomch.com/maemaps.html) > > As it is a always online app anyway, I would like to distribute through > Extras not an offline version, but just a bookmark to the online version. > This would have the advantage for endusers that people can easily find it > through the Application Catalog and for me as a developer greater freedom in > updaating and integration with other services. > > Is that allowed and acceptable? Does it make sense in my case? What would you > do in such a case? > > Best regards and a happy weekend > -Tom > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras Testing to Extras, again...
Hi, why are you all so keen to get stuff into extras? I have thrown away lots of thumbs-up with all the gpxview updates i did. But i have stopped to care. Some guys having given thumbs down never checked the new versions nor commented if the new version solved their issues. So in fact most people just seem to give thumbs down for karma, not to improve those applications. Thus i have decided to play their game by clicking on "promote" every now or then, but not to care about the result (that's why osm2go actually got 15 thumbs up ... i just never checked if it was ready to go into extras). So my advise: Play the game the way they want you to, but ignore the results. It may be too frustrating to fix things due to user feedback, throw away the thumbs up and then see that these testers actually never come back to see if you've improved things. Be happy ... things could be worse. They might e.g. reduce a developers karma for every thumbs-down one of his apps gets. Or do they? Till Am Freitag 20 November 2009 schrieb Brent Chiodo: > I'm also in roughly the same position as Aniello with my application > TouchSearch [1]. I have a new version ready to be released but will > not throw away seven thumbs up to do it... > > I wish I could just upload it to Extras now; it's a simple Desktop > Widget, I think seven people saying it is working fine is enough! > > [1] > http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/touchsearch/1.2-2/ > > > On 11/19/09, Aniello Del Sorbo wrote: > > So... > > > > I am sure I missed something... but what actions were taken to address > > this issue? > > I do have Xournal pacakge 20 for more than 10 days with 6 thumbs up > > out of 10 (i.e. more than 50% of people voted OK). > > > > I want to promote it to Extras. > > And I don't want to depend on others. > > > > I REALLY would like to see a Promote to Extras earlier in the process. > > It's up to me to wait enough time so that people can test it. > > Again, what I think it's missing is something to vote after the > > packages has been promoted to Extras so that the bad ones can > > be pulled out. > > > > If the fear is for malicious applications, then there's no way we can > > prevent those from going to Extras no matter how many days > > it's been in Testing. > > (a timer comes to mind). > > > > Anyway... actions should be taken and asap. > > Please. > > > > -- > > anidel > > Sent from London, Eng, United Kingdom > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: What to backup in fremantle?
Hi, i actually did copy an entire system that way, but that also involved a backup to the external card. My problems are a) the default backup location is the internal card b) the system doesn't differ between the card, so whatever goes into backups to the external card also goes into backup on the internal one Till - original Nachricht Betreff: Re: What to backup in fremantle? Gesendet: Di, 17. Nov 2009 Von: Aniello Del Sorbo > 2009/11/17 Till Harbaum : > > Hi, > > > > i have been asked to add the gpxview application data into the system > backup > > > (http://maemo.org/packages/package_instance/view/fremantle_extras-testing_fr > ee_armel/gpxview/0.8.13-1/) > > > > Now i see a fundamental problem here. All this data _is_ already stored on > the internal > > memory card for exactly the reason of surviving a re-flash. The problem is > that the backup > > is usually also stored on exactly that card (unless you explicitely ask to > have it stored on the > > external one). > > > > So whenever my application data is lost (e.g. due to flashing of a new mmc > image) the backups > > on the internal card are also lost making any inclusion of my data into > these backups rather > > futile. > > > > What is the correct way to handle this? What should go into the backup and > is anything from the > > internal memory card supposed to go into the backup or not? > > > > Till > > > > I never tried this, but I could back-up my N900 and bring the back-up > on a new unit and restore it there. > Say the first N900 has to be brought for some reason back to Nokia > (breaks later, loan expires, you name it). > > In general, if you can't think of use cases, do it anyway, you never > know what people could come up with. > > -- > anidel > Sent from London, Eng, United Kingdom > --- original Nachricht Ende ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
What to backup in fremantle?
Hi, i have been asked to add the gpxview application data into the system backup (http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/gpxview/0.8.13-1/) Now i see a fundamental problem here. All this data _is_ already stored on the internal memory card for exactly the reason of surviving a re-flash. The problem is that the backup is usually also stored on exactly that card (unless you explicitely ask to have it stored on the external one). So whenever my application data is lost (e.g. due to flashing of a new mmc image) the backups on the internal card are also lost making any inclusion of my data into these backups rather futile. What is the correct way to handle this? What should go into the backup and is anything from the internal memory card supposed to go into the backup or not? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package does not end up in DIABLO extras-devel
Hi, the same happened to gpxview 0.8.13-1. I emailed Niels about this but he did not yet reply. Till Am Mittwoch 11 November 2009 schrieb Cornelius Hald: > Same problem here. Yesterday I did build conboy-unstable 0.6.1.1 for > both Diablo and Fremantle. In Fremantle extras-devel it is, in Diablo > extras-devel it's not. > > https://garage.maemo.org/builder/diablo/conboy-unstable_0.6.1.1/ > http://repository.maemo.org/extras-devel/pool/diablo/free/c/conboy-unstable/ > > Cheers! > Conny > > > On Tue, 2009-11-10 at 11:48 -0800, Bruce Forsberg wrote: > > Yes it compiled successfully. The log > > (https://garage.maemo.org/builder/diablo/eboard_1.0.3-9-maemo1/) > > says: > > > > [2009-11-10 11:10:13] Processing package eboard 1.0.3-9-maemo1. > > Uploader: bforsberg, builder: builder2 > > [2009-11-10 11:10:23] Building eboard 1.0.3-9-maemo1 for target > > 'maemo-diablo-armel-extras-devel' > > [2009-11-10 11:42:17] OK > > [2009-11-10 11:42:19] Building eboard 1.0.3-9-maemo1 for target > > 'maemo-diablo-i386-extras-devel' > > [2009-11-10 12:17:36] OK > > [2009-11-10 12:17:37] Signing build results > > [2009-11-10 12:17:38] eboard 1.0.3-9-maemo1 has been queued for > > loading into diablo extras-devel repository > > > > It says it has been queued. But I never see it in extras-devel. > > > > Bruce > > > > On Tue, Nov 10, 2009 at 11:31 AM, Frank Banul wrote: > > > You should have received an email from the Maemo Extras Builder, in it > > > there should be a link to the logs. > > > > > > https://garage.maemo.org/builder/diablo/ > > > > > > Frank > > > > > > On Tue, Nov 10, 2009 at 1:19 PM, Bruce Forsberg > > > wrote: > > >> I am working on porting eboard, which is in OS2007, to OS2008 DIABLO. > > >> I have got it to compile successfully with the autobuilder but the > > >> package never ends up in extras-devel. I have a Section: entry of > > >> user/games. Is there a log somewhere that I can look at to find what > > >> is wrong with my package so that I can fix it? > > >> > > >> Thanks, > > >> Bruce > > >> ___ > > >> maemo-developers mailing list > > >> maemo-developers@maemo.org > > >> https://lists.maemo.org/mailman/listinfo/maemo-developers > > >> > > > > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo5 on Beagleboard
Hi, Am Mittwoch 04 November 2009 schrieb Henning Heinold: > did you download the latest driver from > http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm ? Nope, i am using the driver that is present in the kernel. > It comes with binary calibration and configure program called Touchkit, > which resolve your touchscreen problems. There is one funny think to notice > the right mouse click is emulated be holding the touchscreen for some time, > but this is configurable to your needs via the Touchkit-program. Did you successfully run this program on maemo5 on the beagleboard? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to remove an app from extras-testing?
Hi, how can i have programs removed from extras-testing? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Testing nonsense
Hi, there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a "thumbs down" for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. My proposals: - Add links to the apps changelogs to the package rating page - Add a small text telling the people what they are supposed to test (not harmattan gui portability!!) - Add a link to the bug tracker, so people can file appropriate bugs which can then be processed in a useful manner Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RE: Re: Maemo5 on Beagleboard
Hi, > It's in the alpha patch Found it. Unfortunately it doesn't help. I think i need some help of an x-server expert here. The problems with my touchscreen are related to this: (**) eGalax Inc. USB TouchController: Device: "/dev/input/event3" (**) eGalax Inc. USB TouchController: Calibration factors: 200 3910 3761 180 0 0 (II) eGalax Inc. USB TouchController: Found x and y absolute axes The calibration factors are completely nonsense and in fact the behaviour of the touch makes sense when taking these numbers into account. But my touch needs 100 1900 100 1900 0 0 Where do these default numbers come from? Adding some section like described here http://www.conan.de/touchscreen/evtouch.html does not have any impact on these wrong numbers. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Maemo5 on Beagleboard
Hi, Thomas Kulve wrote: > I don't get the cursor with tuxpaint. Did you modify the libmatchbox2 > and rebuild hildon-desktop? Nope, i didn't change anything. If you just start tuxpaint without touching the mouse at all, you should see the cursor in the screen center. Once you touch it, it nearly immedtialy jumps of to the border. The mouse really behaves weird and nearly immediately jumps into one of the screen corners/borders. Have you ever used a mouse with wrong protocol settings (e.g. ps2 with an imps2 mouse)? The current situation looks pretty much the same. Perhaps it is even something like that. I know the alpha port used a seperate xorg.conf which had to be invoked this way: -:~# Xorg -config /etc/xorg.conf-beagle & I don't have a alpha setup anymore. Has one of you access to this old xorg.conf-beagle? If yes, can you please post it so we can use it as a replacement? > No. I can use it to unblank the screen.. Me too :-) Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo5 on Beagleboard
Hi, here's my current status: The board is booting and i get a 800x600 image (on my 800x480 display :-( ) USB works, but neither touchscreen nor mouse are really doing what i expect them to do. I am able to establish a WLAN connection to my home network. In order to make this work three things have to be done: 1) Install everything necessary to use our particular WLAN stick (e.g. incl. wpa_supplicant if your are using wpa in your home network as in my case) 2) Change in /etc/udhcpc/default.bound RESOLV_CONF="/var/run/resolv.conf" to RESOLV_CONF="/etc/resolv.conf" in order to make udhcp change the main resolv.conf as we are not running a local name server 3) Copy the sources.list used to build the rootfs into the rootfs at /etc/apt You should now be able to do such things like "apt-get update" and the like. Now for the problem: I haven't yet been able to work with the mouse or the touchscreen in a useful manner. The most useful tool i found so far to test the mouse/touchscreen input is "tuxpaint". If you have a working network connection as stated above you can just apt-get install tuxpaint. Starting tuxpaint from the console immediately gives you a visible mouse pointer. So this is a simple way to actually see what your inout devices are doing. Sometimes (e.g. if you rebooted while tuxpaint was running, it won't restart as it thinks it's already running. In that case delete the file /media/mmc1/tuxpaint/lockfile.dat What's your state? Has anyone actually been able to do something with the mouse? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Maemo5 on Beagle
Hi, i just disabled the two main CPU Power Management switches (CPU frequency scaling and CPU idle PM support) and the uart/console now doesn't have any problems anymore and also the system now seems to run stable. Get it here: http://www.harbaum.org/till/uImage_Maemo5_no_PM.bz2 Till - original Nachricht Betreff: Re: Maemo5 on Beagle Gesendet: Do, 29. Okt 2009 Von: Dirk Behme > Till Harbaum wrote: > > Hi, > > > > - original Nachricht > >> Would we have a chance to disable console sleep recompiling the kernel > >> (like Till tried?). Should we ask some PM experts for this, e.g. Kevin? > > That may actually make sense for the beagleboard as these will likely > never > > be run on battery. > > While thinking about this: Would it make sense to disable power > management for Beagle kernel completely? Or will Maemo5 have a problem > then? > > Till: Maybe you like to try this while building your own kernel? > > Cheers > > Dirk > --- original Nachricht Ende ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
