Re: [maemo-developers] Application Catalog rewrite [was: Abuse on the ApplicationCatalog page]
On 4/11/06, Michael Wiktowy [EMAIL PROTECTED] wrote: That way, once an app is added to the index page, the information on there does not need to be updated each time the detail page is updated. Makes it easier to maintain. Indeed, however one thing which I'd like to keep in mind is my ApplicationCatalog - RSS feed[1] which, although currently unavailable[2], is relatively easy to put together with the existing design. Having to check a page for each application for updates would be more of a pain. For users not using the RSS feed, being able to look at a single page with the latest version numbers on is useful, I think. There's also no point in having a page per application in the Maemo wiki: there's no file hosting abilities so a separate download/homepage will be required elsewhere, I'd be happy seeing a short, structured index page like Jussi suggests. Perhaps if there is a page per app, it could be a comments or discussion page like Wikipedia's Talk: prefixes. No official stuff there about how to use the app, but a way for users to discuss it if necessary. Two main groups of indicies should be Maemo Applications (apps that run in the 770 itself) and Maemo Support Applications (apps that run on a computer that connects to the 770 which has the primary purpose of supporting the 770 in some way [snip]) That sounds sensible. Cheers, Andrew [1] http://www.bleb.org/software/770/#rss [2] Status of the availability of bleb.org at: http://aflegg.googlepages.com/tv -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Application Catalog rewrite
Michael Wiktowy wrote: I made a mockup of All Maemo Applications at https://maemo.org/maemowiki/ApplicationCatalogMockup . Please comment and/or modify the page. If there is going to be a more detailed page for each app, I would replace the Homepage and Download links with a Details link pointing to the more detailed application-specific page ... But this is the catch: some people want to update the info on their own web page (and want people to visit their page) and I think that's fair. I propose only creating application-specific pages when they're needed (when there's no outside resource) -- this also minimizes the work needed to keep the wiki up to date. ... and a Status indicator to let people know if the app is a WIP, Alpha, Beta, Stable release. I considered this, but I thought it too fine grained and subjective: Besides, we would already have end-user ready / stable / WIP indication implicitly with the different pages. Two main groups of indicies should be Maemo Applications (apps that run in the 770 itself) and Maemo Support Applications (apps that run on a computer that connects to the 770 which has the primary purpose of supporting the 770 in some way ... be it converting media, browser plugins, sync tools) Support Apps on another page is a very good idea. -- Jussi Kukkonen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Application Catalog rewrite [was: Abuse on the ApplicationCatalog page]
Hi, Santeri Lindgren wrote: As i proposed (might be a lot of typing errors), i propose that the ApplicationCatalog -page, as other equivalents to this, Wip and Wishlist. Should only be a list, maybe categorized more specifically. Making the list a really long, isn't very nice when using GPRS to browse and search one app you know is in the page but you dont' remember the homepage or something. That way, once an app is added to the index page, the information on there does not need to be updated each time the detail page is updated. Makes it easier to maintain. Yes, this is a good point, but also, if you make a detailed index page, it gets cramped. If you want some details to the index page, something like: gategory | app name| few centences nothing more I've modified https://maemo.org/maemowiki/ApplicationCatalogMockup into a more minimal look, would that be an acceptable compromise? Go ahead and make the table continuous if you want, that would make the page more compact. I'm not sure it would enhance readability, though. Then each of those groups could be subdivided into functional groups (Network, PIM, etc.) like they are now. So, three pages? index - group - application. Probably not what he meant. Currently they're on the same page, but under different headers. I think this approach is sensible (taking into account maintainability, ease of search and machine-readability Andrew mentioned). -- Jussi Kukkonen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Maemo kit development and remote access
Hi again, I will try to be more precise, last time I wasn't at work. So when I run: af-sb-init.sh start in my ssh client, I see in the xephyr window the environnement trying to run but it disappeared immediatly. And I have this error message: - x-SDK_PC: ~] af-sb-init.sh start Sample files present. Starting Maemo Launcher: maemo-launcher start failed. Starting DBUS system bus Starting D-BUS session bus daemon Sapwood image server is already running, doing nothing Starting Matchbox window manager Keyboard is already running, doing nothing root window unavailible (maybe another wm is running?) Starting MAEMO AF Desktop [sbox-SDK_PC: ~] maemo_af_desktop[16427]: GLIB CRITICAL ** GLib-GObject - g_object_set: assertion `G_IS_OBJECT (object)' failed maemo_af_desktop[16427]: osso_state_close:282: Unable to close state file: Bad file descriptor TRACE LOG: status_bar_main: 1 g_new0 TRACE LOG: status_bar_main: 2 check panel ptr TRACE LOG: status_bar_main: 3: init dock TRACE LOG: status_bar_main: 4 add prespecified items maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin sound: /usr/lib/hildon-status-bar/libsound.so: cannot open shared object file: No such file or directory maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin sound maemo_af_desktop[16427]: Item not properly loaded. This function is only called, if a item couldn't initialise itself properly. See hildon_status_bar_item_init/new for more information maemo_af_desktop[16427]: Statusbar item add failed for sound maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin internet: /usr/lib/hildon-status-bar/libinternet.so: cannot open shared object file: No such file or directory maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin internet maemo_af_desktop[16427]: Item not properly loaded. This function is only called, if a item couldn't initialise itself properly. See hildon_status_bar_item_init/new for more information maemo_af_desktop[16427]: Statusbar item add failed for internet maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin gateway: /usr/lib/hildon-status-bar/libgateway.so: cannot open shared object file: No such file or directory maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin gateway maemo_af_desktop[16427]: Item not properly loaded. This function is only called, if a item couldn't initialise itself properly. See hildon_status_bar_item_init/new for more information maemo_af_desktop[16427]: Statusbar item add failed for gateway maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin battery: /usr/lib/hildon-status-bar/libbattery.so: cannot open shared object file: No such file or directory maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin battery maemo_af_desktop[16427]: Item not properly loaded. This function is only called, if a item couldn't initialise itself properly. See hildon_status_bar_item_init/new for more information maemo_af_desktop[16427]: Statusbar item add failed for battery maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin display: /usr/lib/hildon-status-bar/libdisplay.so: cannot open shared object file: No such file or directory maemo_af_desktop[16427]: HildonStatusBarItem: Unable to open plugin display maemo_af_desktop[16427]: Item not properly loaded. This function is only called, if a item couldn't initialise itself properly. See hildon_status_bar_item_init/new for more information maemo_af_desktop[16427]: Statusbar item add failed for display TRACE LOG: status_bar_main: 5 add user items TRACE LOG: status_bar_main: 6 gtk widget show all TRACE LOG: status_bar_main: 7 if rpc... TRACE LOG: status_bar_main: 8, status bar initialized successfully sapwood-server[16289]: GLIB WARNING ** Gdk - The gdk_draw_*_image require the drawable argument to have a specified colormap. All windows have a colormap, however, pixmaps only have colormap by default if they were created with a non-NULL window argument. Otherwise a colormap must be set on them with gdk_drawable_set_colormap maemo_af_desktop[16427]: GLIB WARNING ** default - qgn_plat_task_navigation_button_03_normal.png: pixmap[1][1]: gdk_pixmap_foreign_new(83) failed maemo_af_desktop[16427]: GLIB WARNING ** default - Ai maemo_af_desktop[16427]: GLIB WARNING ** default - qgn_plat_task_navigation_button_03_normal.png: pixmask[1][1]: no pixmap sapwood-server[16289]: GLIB WARNING ** Gdk - The gdk_draw_*_image require the drawable argument to have a specified colormap. All windows have a colormap, however, pixmaps only have colormap by default if they were
Re: [maemo-developers] Re: Abuse on the ApplicationCatalog page
Cool! You can have 'Ported' and 'Polished' package pages. Sounds good. I am confused - shouldn't the 'UNpolished' Applications be in the [annoyingly named]WIP page? Stephen On 4/11/06, Tuomas Kuosmanen [EMAIL PROTECTED] wrote: What do you guys think of such a refactoring where the *main* application catalog would contain software that has been ported a bit further than just wow, it runs! Here is a package to try out! On 4/11/06, Tuomas Kuosmanen [EMAIL PROTECTED] wrote: On Wed, 2006-04-05 at 23:05 +0930, ext Stephen DeGabrielle wrote: With that in mind, I think it is probably time that the ApplicationCatalog was refactored into multiple pages, as it is a 128kb monster at the moment and painful to edit. Of course being so large is probably discouraging edits a little so maybe it's not a bad thing. I might refactor it myself. (Probably not - so maybe someone else will.) What do you guys think of such a refactoring where the *main* application catalog would contain software that has been ported a bit further than just wow, it runs! Here is a package to try out! There's a lot of interesting stuff going on with porting and making things run on the device and maybe providing .deb's is an important first step. But there is still work to be done to make it fit the Maemo desktop and environment, polishing the packaging to make it fit the menus, perhaps adding the dbus service stuff etc. I am thinking of a rough outline of a process what it takes to fully port an application: * basic it works! porting work to make it run, if changes are even needed in the code itself * packaging for the application installer (where to put it in the menus, adding the dbus stuff to make the starting foobar... -notifications work etc.. * hildonizing the UI (menus, toolbars etc) * Possibly rethinking the user interface even further to make it work better in a tablet environment [*] * Ideally working with the original maintainer (if not the same person) to get maemo-specific changes integrated upstream, ideally maintaining the maemo port in the same code tree as the original to reduce forking and making sure the port lives with the parent project if possible. Did I miss something? Does it make sense to you to have this kind of raised bar for the main catalog? [*] As you might remember I'm here to help you with the user interface part, and in many cases it is not *that much* work to get there. :) And well, many times this could also result in good ideas for the parent application's user interface. I think having such a distinction in the app catalog could be good in making us more motivated to making better ports? Comments? //Tuomas -- A: No Q: Should i quote this on the top? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- -- Stephen De Gabrielle ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Zapped wtmp...
I don't know about JFFS2 but back in the old days before Linux yuo could be pretty sure that a Unix filesystem didn't waste space storing null bytes. Wtmp and other system files (databases?) take advantage of this. Now you've made me aware of this I've deleted /var/log/wtmp. I doubt it was using as much storage as you suggest but if I'd really been thinking I'd have done a df before and after - maybe someone else will. There's no need to link it to anything. If the file isn't there, then logging is turned off - at least that's what should happen. Michael - Original Message - From: Nils Faerber [EMAIL PROTECTED] To: maemo-developers@maemo.org Sent: Wednesday, April 12, 2006 3:34 PM Subject: [maemo-developers] Zapped wtmp... Hi! I thought I should let you know... I am not sure if I really found any cure to anything but after the latest discussions about the size of wtmp I checked mine on the 770 and found a more than 200MB file! After gzip'ping it it shrank to just 5MB because it contains almost only 0s. But there must be the information for 200MB stored somewhere in the JFFS2 so I guess that even if it only has 5MB as a comporessed file the impact on a JFFS2 can be much worse. So I enabled the RD mode, became root and linked /var/log/wtmp to /dev/null (who cares for this wtmp on the 770 anyway?). Before I did this I saw more and more weird phenomena on the device, like crashing browser and spurious power-offs when case closed (almost 100% battery, closed device one night, next morning it was powered off and had to be rebooted!). Now after I zapped wtmp I have the feeling (!) that it behaves much better again! I can browse pages that before did not work and I hope that the power-downs are history now too (for the last three days they are but you never know). Maybe someone else likes to try to this too and report his/her experience here. Probably wtmp should be linked to /dev/null in the next software release too. BTW: With every closure of the case the wtmp grows by about 3kB. You can estimate with your usage how big it will get... Cheers nils faerber -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 -- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Zapped wtmp...
Michael Saunby wrote: I don't know about JFFS2 but back in the old days before Linux yuo could be pretty sure that a Unix filesystem didn't waste space storing null bytes. Wtmp and other system files (databases?) take advantage of this. Now you've made me aware of this I've deleted /var/log/wtmp. I doubt it was using as much storage as you suggest but if I'd really been thinking I'd have done a df before and after - maybe someone else will. There's no need to link it to anything. If the file isn't there, then logging is turned off - at least that's what should happen. Wrong, this just deletes everything that is stored prior to this. And no, what you assume is wrong. Of course the log files should be erasable, and if user deletes the log file, then the system should just start making a new one. Creating the log file if it's not there is the right thing. and turning off the logging should be done via config file. And, my wtmp file was 96.5MB, will be posting if the linking helped anything. And yes, i have too found that the system is more sluggish than in the beginning of use. Even enabling swap-space on the mmc dont have any help anymore. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Zapped wtmp...
There's no need to link it to anything. If the file isn't there, then logging is turned off - at least that's what should happen. Wrong, this just deletes everything that is stored prior to this. And no, what you assume is wrong. Of course the log files should be erasable, and if user deletes the log file, then the system should just start making a new one. Without addressing the question of what the behavior should be, man wtmp on my FC4 system states that logging is disabled if wtmp doesn't exist: wtmp is maintained by login(1), init(1), and some versions of getty(1). Neither of these programs creates the file, so if it is removed, record-keeping is turned off. If you've confirmed that the 770 handles things differently, that's useful information. Your tone is somewhat excessive, though, especially considering that Michael Saunby's claim is supported by at least some related documentation. Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Zapped wtmp...
Michael P. Lococo wrote: There's no need to link it to anything. If the file isn't there, then logging is turned off - at least that's what should happen. Wrong, this just deletes everything that is stored prior to this. And no, what you assume is wrong. Of course the log files should be erasable, and if user deletes the log file, then the system should just start making a new one. Without addressing the question of what the behavior should be, man wtmp on my FC4 system states that logging is disabled if wtmp doesn't exist: wtmp is maintained by login(1), init(1), and some versions of getty(1). Neither of these programs creates the file, so if it is removed, record-keeping is turned off. If you've confirmed that the 770 handles things differently, that's useful information. Your tone is somewhat excessive, though, especially considering that Michael Saunby's claim is supported by at least some related documentation. Mike Sorry if it feels like that, it wasn't meant to be like that. But, yes, the wtmp is created after it is removed. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
