Re: Fremantle UI Portrait Mode
On Tue, Jun 02, 2009 at 08:09:36PM +0200, Cornelius Hald wrote: > this mail got a bit longer then I expected. And the reply took longer than I expected too :) Please accept my apologies. > I think most people who use filters and the portrait mode will have > to create a different version of the menu for portrait mode. In my > opinion there is just not enough space to put them in one row. Yes, that's probably true, but I think it'll happen to other parts of the UI as well. It's not easy to design an application that looks fine both in portrait and landscape with the UI unchanged (but I admit I'm not a UI designer) :) Wrt filters, you're right that it's harder to use them in portrait mode. The problem is that Fremantle was designed to be used mostly in landscape, with portrait being used in a few exceptional cases. > > Standard (Gtk) toolbars don't change, because I don't think > > there's a reliable and generic way to change their layout. [...] > > The same applies to many other widgets and the whole program UI > > in general (if it's going to support portrait mode it should be > > designed with that in mind). > Hmm... Well, I think the toolkit should do as much as possible for > the developer. If the developer wants to override all this magical > stuff, then there surely should be a way to do so. Well, I know what you mean but please understand that we have to focus on some very important bugs and having the basic stuff working right before adding those extra niceties :) > 1a) Introduce some kind of "important" property for widgets. Using > this, I could mark some of my buttons as important and thus the UI > would make sure that they are shown even in portrait mode. Buttons > or widgets without that flag could be omitted or put into a sub menu > if there is not enough space. This can be done very easily if you hide the "unimportant" options when the screen rotates. Connect to the "size-changed" signal and then call gtk_widget_hide() All other menu items will rearrange when you hide/show any of them. > 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it > like the AppMenu? That was our initial plan, but due to several technical reasons we saw that it was not feasible and decided to create a different widget. > All in all I think that the Gtk-API should be used more, but that > the rendering on the screen should just different from the rendering > on the desktop. We try to do that where possible. Sometimes it's just a matter of theming the widget correctly, but other times it requires significant changes to Gtk, and the maemo-Gtk maintainers try to keep it as close to upstream as possible, because maintaining a big fork is a hard task, but they can tell you better than me :) Another thing is that legacy (i.e. pre-Fremantle) apps should look more or less the same (i.e., consistent within themselves). If we change the internals of many Gtk widgets to make them match the Fremantle UI style, old apps could look very weird. > If I remember correctly there was quite some effort for Maemo 4.0 to > remove own/specific API and replace them with existing API, now it > looks like we´re going into the other direction again. My personal opinion from what I can see is that Maemo 4 (and previous versions) had a UI style much closer to desktop apps, and Maemo 5 is VERY different in that sense. Implementing all the requires changes in Gtk while maintaining compatibility with previous versions is very very difficult. Or, in other words, making a desktop app that also looks like a Fremantle app with no changes in the code is basically impossible. Of course I admit that we could have made some mistakes, but believe me, we try to avoid creating new widgets unless it's necessary. > Thanks for reading! Thanks for writing :) and sorry again for the delay. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
On 06/11/2009 05:01 PM, Jamie Bennett wrote: > Forgive my ignorance but is it 10x longer to compile or 10x increment > in speed? Compilation speed is a matter of grabbing two coffee's > instead of one, run time speed is a matter of giving up completely. C code compiled by g++ isn't slower or faster. It should be the same. (I'm talking runtime speed here) Just because there seems to be another myth being entertained. Hub ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
heh Jamie, its 10x (might be slight exag) longer to compile. i normally make code changes and compile the 2 or 3 modules I've been working on. its quick and simple. with c++ even the simplest files are slow. its like waiting for visual studio to run, an age. and my method of on device compilation is FASTER for normal day to day coding than scratchbox and copy and execute :) its got obvious serious drawbacks tho lol gary On Thu, Jun 11, 2009 at 10:01 PM, Jamie Bennett wrote: > > On 11 Jun 2009, at 21:08, gary liquid wrote: > >> Hubert, >> >> Compiling my pure C in a C++ compiler is indeed possible. >> However, it takes 10x longer on my tablet to compile even simple >> programs using a c++ compiler. >> >> I don't mind if the libs aren't available, it was just a nicety for me >> - there will be other libraries that are usable as required I am sure. > > Forgive my ignorance but is it 10x longer to compile or 10x increment in > speed? Compilation speed is a matter of grabbing two coffee's instead of > one, run time speed is a matter of giving up completely. (oh and compiling > on the tablet is so 1980's ;) ) > >> Gary > > Regards, > Jamie. > -- > http://www.linuxuk.org > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
On 11 Jun 2009, at 21:08, gary liquid wrote: > Hubert, > > Compiling my pure C in a C++ compiler is indeed possible. > However, it takes 10x longer on my tablet to compile even simple > programs using a c++ compiler. > > I don't mind if the libs aren't available, it was just a nicety for me > - there will be other libraries that are usable as required I am sure. Forgive my ignorance but is it 10x longer to compile or 10x increment in speed? Compilation speed is a matter of grabbing two coffee's instead of one, run time speed is a matter of giving up completely. (oh and compiling on the tablet is so 1980's ;) ) > Gary Regards, Jamie. -- http://www.linuxuk.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
Hubert, Compiling my pure C in a C++ compiler is indeed possible. However, it takes 10x longer on my tablet to compile even simple programs using a c++ compiler. I don't mind if the libs aren't available, it was just a nicety for me - there will be other libraries that are usable as required I am sure. Gary On Thu, Jun 11, 2009 at 5:15 PM, Hubert Figuiere wrote: > On 06/10/2009 07:32 AM, Sampo Savola wrote: >> There seems to be only C++ interface for this. > > >> How should this be used in C application, >> is there going to be C interface also? > > You can mix C and C++ easily. You can recompile your C code with a C++ > compiler[1]. > > > Hub > > [1] possibly with a few changes that will keep the code compilable with > a C compiler. This was part of the C++ design. > ___ > 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: calendar-backend
On 11 Jun 2009, at 17:15, Hubert Figuiere wrote: > On 06/10/2009 07:32 AM, Sampo Savola wrote: >> There seems to be only C++ interface for this. >> >> How should this be used in C application, >> is there going to be C interface also? > > You can mix C and C++ easily. You can recompile your C code with a C++ > compiler[1]. Anyway, C is a just a C++ revolutionists realization of a programming language. Some day they will come back and say, what was I thinking. Hey I should print that on a t-shirt. > Hub Regards, Jamie. -- http://www.linuxuk.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Am Donnerstag, 11. Juni 2009 schrieb Rainer Dorsch:
> [...]
> > More details is in /mnt/initfs/linuxrc in function enter_state(), normal
> > mode is USER state, charging mode is (or is one case of?) ACTDEAD state.
> > I hope I am not wrong about this.
>
> After investigating linuxrc the above behavior becomes clear:
>
> show_actdead_image()
> {
> bootreason=`cat /proc/bootreason`
> if [ x"$bootreason" = x"charger" ]; then
> echo "Showing the 'charger connected' image"
> /usr/bin/fb-chaimage -l
> /usr/share/images/qgn_indi_charger_connection_detected -b 0 -c -p 0 -s 15 &
> fi
> }
>
> It seems that /proc/bootreason was not charger in my case (and I think that
> is expected when the N800 crashed).
>
> I modified that too
>
> if [ x"$bootreason" = x"charger" ]; then
> echo "Showing the 'charger connected' image"
> /usr/bin/fb-chaimage -l
> /usr/share/images/qgn_indi_charger_connection_detected -b 0 -c -p 0 -s 15 &
> else
> text2screen -t "Bootreason: `cat /proc/bootreason`" -H center -y
> 360 -s 6 -B 0x
> fi
>
> This way I have at least some information when I run in that problem next
> time.
>
> Is there any other debug information which would be useful to print? Is
> there a way (by changing linuxrc further) to get a lot more information
> during boot instead of the nice but almost informationfree image?
I just noticed that I cannot write that file, the fs is mounted readonly:
/dev/root on /mnt/initfs type jffs2 (ro)
If I remount it rw
mount -o remount,rw /mnt/initfs
to do the change, would that break something?
Thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Frantisek,
many thanks for your detailed explanation.
Am Dienstag, 9. Juni 2009 schrieb Frantisek Dufka:
> Rainer Dorsch wrote:
> > Under which circumstances is the N800 started automatically, when the
> > power supply is plugged in?
>
> N800 is always started when you plug it in. The difference is in unix
> runlevel the device boots into. Normal is runlevel 2 when maemo-desktop
> starts fully. When bootreason (/proc/bootreason) is 'charger' it boots
> into runlevel 5 with slightly different boot sequence which in final
> stage shows only charging icon but otherwise the system behind it is
> almost fully booted. So in theory you can have reboot loop which happens
> only in runlevel 5 and not in runlevel 2 if the failing part is specific
> to runlevel 5. Maybe you saw this?
I was not aware of that behavior. Right now, I see exactly what you describe.
When I was in the power cycle loop, I saw after plugging in the power supply,
that the blue progress bar at the bottom and it completed. Now when I plug in
the power supply, I do not see the blue progress bar, but the charging icon.
> More details is in /mnt/initfs/linuxrc in function enter_state(), normal
> mode is USER state, charging mode is (or is one case of?) ACTDEAD state.
> I hope I am not wrong about this.
After investigating linuxrc the above behavior becomes clear:
show_actdead_image()
{
bootreason=`cat /proc/bootreason`
if [ x"$bootreason" = x"charger" ]; then
echo "Showing the 'charger connected' image"
/usr/bin/fb-chaimage -l
/usr/share/images/qgn_indi_charger_connection_detected -b
0 -c -p 0 -s 15 &
fi
}
It seems that /proc/bootreason was not charger in my case (and I think that is
expected when the N800 crashed).
I modified that too
if [ x"$bootreason" = x"charger" ]; then
echo "Showing the 'charger connected' image"
/usr/bin/fb-chaimage -l
/usr/share/images/qgn_indi_charger_connection_detected -b
0 -c -p 0 -s 15 &
else
text2screen -t "Bootreason: `cat /proc/bootreason`" -H center -y
360 -s 6 -B 0x
fi
This way I have at least some information when I run in that problem next
time.
Is there any other debug information which would be useful to print? Is there
a way (by changing linuxrc further) to get a lot more information during boot
instead of the nice but almost informationfree image?
> Personally I don't like this behaviour so I am always powering device by
> power key and if I know battery is empty I have charger prepared and
> plug it in just after screen lights up to avoid this charging mode.
> There is short window of time to do this before dsme/bme starts and
> decides to shutdown the system due to low battery.
It is definitely worthwhile to know that there is a different behavior (and to
understand the power cycle loops might be broken when booting w/o power
supply).
> It would be interesting to modify linuxrc to go to runlevel 2 even in
> this charging state and see if it manages to boot normally.
I do not know how to reproduce the problem, so I cannot tell.
Thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
On 06/10/2009 07:32 AM, Sampo Savola wrote: > There seems to be only C++ interface for this. > > How should this be used in C application, > is there going to be C interface also? You can mix C and C++ easily. You can recompile your C code with a C++ compiler[1]. Hub [1] possibly with a few changes that will keep the code compilable with a C compiler. This was part of the C++ design. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Easy way of testing fremantle build?
On Thu, 2009-06-11 at 11:35 +0200, ext ds wrote: > Hi, > > I just feed my application (vnc viewer diablo source) to > fremantle-extras-builder and it is indicated, that it build > without any > problems. > > What is the easiest way, to test it, without installing the > whole sdk? > > I have one portability issue: I need to have the X-server screen > in the > 16-bit color mode of previous N770, N800 and N810, as for reason > of > quick application response this was highly optimized. Of cause > this > could be changed quite quickly to another color mode, but where > can I > get information on the upcoming color mode on the maemo 5 > devices. I'm afraid we'll have 16-bit colours as default, so you don't have to do anything in that regard. Most of the SW will support 32 as well, but not all. -Kimmo > > Thanks a lot > > Detlef > > > > ___ > 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: Easy way of testing fremantle build?
Detlef Schmicker wrote: > Thanks for the quick response, > > I could not find a vm image with fremantle installed, do you know where > to find? Ah sorry, I was in a hurry and didn´t check my facts :( The available image does not include the Fremantle SDK - it´s only Diablo. I was misreading this announcement: http://maemo.org/news/announcements/maemo_sdk_virtual_image_released Sorry again! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Easy way of testing fremantle build?
On Thu, 2009-06-11 at 11:35 +0200, ds wrote: > What is the easiest way, to test it, without installing the > whole sdk? Somehow you'll need to have the SDK. If you don't want to install it and disk space doesn't matter, I would recommend you to use the VMWare/VirtualBox image which has the SDK etc. already installed. Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Easy way of testing fremantle build?
Hi, I just feed my application (vnc viewer diablo source) to fremantle-extras-builder and it is indicated, that it build without any problems. What is the easiest way, to test it, without installing the whole sdk? I have one portability issue: I need to have the X-server screen in the 16-bit color mode of previous N770, N800 and N810, as for reason of quick application response this was highly optimized. Of cause this could be changed quite quickly to another color mode, but where can I get information on the upcoming color mode on the maemo 5 devices. Thanks a lot Detlef ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
Hello! I asked the guys responsible for calendar area.. seems that having a C API is not very likely. Adding Ilias in CC who is the owner of this area. -Soumya On Wed, 2009-06-10 at 13:36 +0200, ext gary liquid wrote: > Sampo, > > I would also be interested in a C api to the same calendar backend. > Obviously my calendar is very simplistic and sketch based, but it > would be of obvious benefit to allow system calendar entries to be > visible there :) > > > Gary > > > > On Wed, Jun 10, 2009 at 12:32 PM, Sampo Savola wrote: > > Hey > > > > With Fremantle beta sdk there comes this, calendar-backend : > > http://maemo.org/api_refs/5.0/beta/calendar-backend/ > > > > There seems to be only C++ interface for this. > > > > How should this be used in C application, > > is there going to be C interface also? > > > > //Sampo > > > > ___ > > 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
