Re: shr-contacts/messages/dialer: window size and further issues

2009-09-17 Thread Rui Miguel Silva Seabra
On Thu, Sep 17, 2009 at 09:01:49PM +1000, Carsten Haitzler wrote:
> On Thu, 17 Sep 2009 09:49:26 +0400 "Nikita V. Youshchenko" 
> said:
> > > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > > program specified minimum size: 198 by 350
> > > > > > > program specified maximum size: 198 by 350
> > > > > > > ...
> > > > > >
> > > > > > the way the contents are specified for the window, it isnt
> > > > > > resizable. the app
> > > > > > is in control of this.
> > > > >
> > > > > All SHR apps have these values defined as above.
> > > >
> > > > That means that all SHR apps will get non-resizable 198x350 windows
> > > > under any stardards-compliant window manager.
> > > >
> > > > This is definitly a bug that should be fixed.
> > >
> > > not all standards compliant wm's. e+illume will be fine. matchbox
> > > probably too. the "standards" allow the wm to happily ignore min/max
> > > window size hints if the wm wants to. :)
> > 
> > WM hints is *the* standard way for app to request it's size constraints.
> > So if app sets hints, while not wanting to get these size constraints, it 
> > is a bug in app.
> 
> i have said that several times. but the standards do not REQUIRE that a wm 
> MUST
> keep a window between its min and max sizes. it is an optional behavior. thus
> they may be resizable under standards compliant wm's. it's up to the wm.

Which is why they are called *hints* (to everyone else but Carsten who who knows
this way, way better than I do) :)

Actually there's a huge security design flaw in Windows in great part because 
their
windows work in a dramatically different way than X's (IIRC).

Oh, and the only way to fix it requires a fatal retrocompatibility breakage.

Rui

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-17 Thread The Rasterman
On Thu, 17 Sep 2009 09:49:26 +0400 "Nikita V. Youshchenko" 
said:

> > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > program specified minimum size: 198 by 350
> > > > > > program specified maximum size: 198 by 350
> > > > > > ...
> > > > >
> > > > > the way the contents are specified for the window, it isnt
> > > > > resizable. the app
> > > > > is in control of this.
> > > >
> > > > All SHR apps have these values defined as above.
> > >
> > > That means that all SHR apps will get non-resizable 198x350 windows
> > > under any stardards-compliant window manager.
> > >
> > > This is definitly a bug that should be fixed.
> >
> > not all standards compliant wm's. e+illume will be fine. matchbox
> > probably too. the "standards" allow the wm to happily ignore min/max
> > window size hints if the wm wants to. :)
> 
> WM hints is *the* standard way for app to request it's size constraints.
> So if app sets hints, while not wanting to get these size constraints, it 
> is a bug in app.

i have said that several times. but the standards do not REQUIRE that a wm MUST
keep a window between its min and max sizes. it is an optional behavior. thus
they may be resizable under standards compliant wm's. it's up to the wm.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Nikita V. Youshchenko
> > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > program specified minimum size: 198 by 350
> > > > > program specified maximum size: 198 by 350
> > > > > ...
> > > >
> > > > the way the contents are specified for the window, it isnt
> > > > resizable. the app
> > > > is in control of this.
> > >
> > > All SHR apps have these values defined as above.
> >
> > That means that all SHR apps will get non-resizable 198x350 windows
> > under any stardards-compliant window manager.
> >
> > This is definitly a bug that should be fixed.
>
> not all standards compliant wm's. e+illume will be fine. matchbox
> probably too. the "standards" allow the wm to happily ignore min/max
> window size hints if the wm wants to. :)

WM hints is *the* standard way for app to request it's size constraints.
So if app sets hints, while not wanting to get these size constraints, it 
is a bug in app.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread The Rasterman
On Wed, 16 Sep 2009 13:21:10 +0100 Rui Miguel Silva Seabra  said:

> On Wed, Sep 16, 2009 at 04:13:16PM +0400, Nikita V. Youshchenko wrote:
> > > Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > > program specified minimum size: 198 by 350
> > > > > > > program specified maximum size: 198 by 350
> > > > > > > ...
> > > > > >
> > > > > > the way the contents are specified for the window, it isnt
> > > > > > resizable. the app
> > > > > > is in control of this.
> > > > >
> > > > > All SHR apps have these values defined as above.
> > > >
> > > > That means that all SHR apps will get non-resizable 198x350 windows
> > > > under any stardards-compliant window manager.
> > > >
> > > > This is definitly a bug that should be fixed.
> > >
> > > and what is the proposed fix? Use XSetWMSizeHints?
> > 
> > I've never written a line using E libraries, but quick search suggests 
> > evas_object_size_hint_min_set() / evas_object_size_hint_max_set() 
> 
> Like those are of much use when you can turn from portrait to landscape.
> 
> NOT a solution!

it's not an issue if your wm is like e+illume or matchbox and maximises apps
regardless of min/max size.if its a desktop wm rotate is irrelevant here as the
wm wont go resizing the window on rotate anyway, even if it is rotatable. (or
is very unlikely to do this - move the window maybe, resize - unlikely).

you need to differentiate between a wm setting up a sane windowing policy for
such screen sizes and uses and a "desktop" wm and is policies.

i agree the apps should not be relying on the wms ignoring their hints to work
right - they should have their content packed in such a way that they are
resizable. that is the correct solution. then a nice friendly resize of the
window object to a nice size is good too (remember to get the min/max hints
first and respect them in your resize as he resize is not going to respect them)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread The Rasterman
On Wed, 16 Sep 2009 15:37:28 +0400 "Nikita V. Youshchenko" 
said:

> > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > program specified minimum size: 198 by 350
> > > > program specified maximum size: 198 by 350
> > > > ...
> > >
> > > the way the contents are specified for the window, it isnt resizable.
> > > the app
> > > is in control of this.
> >
> > All SHR apps have these values defined as above.
> 
> That means that all SHR apps will get non-resizable 198x350 windows under 
> any stardards-compliant window manager.
> 
> This is definitly a bug that should be fixed.

not all standards compliant wm's. e+illume will be fine. matchbox probably too.
the "standards" allow the wm to happily ignore min/max window size hints if the
wm wants to. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread The Rasterman
On Wed, 16 Sep 2009 14:00:47 +0200 "Klaus 'mrmoku' Kurzmann"
 said:

> Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > program specified minimum size: 198 by 350
> > > > > program specified maximum size: 198 by 350
> > > > > ...
> > > >
> > > > the way the contents are specified for the window, it isnt resizable.
> > > > the app
> > > > is in control of this.
> > >
> > > All SHR apps have these values defined as above.
> >
> > That means that all SHR apps will get non-resizable 198x350 windows under
> > any stardards-compliant window manager.
> >
> > This is definitly a bug that should be fixed.
> and what is the proposed fix? Use XSetWMSizeHints? 

no. just pack things so some window resize object is resizable. actually so all
of them are (weight 1.0 1.0). otherwise non-resizable "resize objects" for the
window will constrain its size to min size of these elements.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Rui Miguel Silva Seabra
On Wed, Sep 16, 2009 at 04:48:58PM +0400, Nikita V. Youshchenko wrote:
> > On Wed, Sep 16, 2009 at 04:13:16PM +0400, Nikita V. Youshchenko wrote:
> > > > Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > > > program specified minimum size: 198 by 350
> > > > > > > > program specified maximum size: 198 by 350
> > > > > > > > ...
> > > > > > >
> > > > > > > the way the contents are specified for the window, it isnt
> > > > > > > resizable. the app
> > > > > > > is in control of this.
> > > > > >
> > > > > > All SHR apps have these values defined as above.
> > > > >
> > > > > That means that all SHR apps will get non-resizable 198x350
> > > > > windows under any stardards-compliant window manager.
> > > > >
> > > > > This is definitly a bug that should be fixed.
> > > >
> > > > and what is the proposed fix? Use XSetWMSizeHints?
> > >
> > > I've never written a line using E libraries, but quick search suggests
> > > evas_object_size_hint_min_set() / evas_object_size_hint_max_set()
> >
> > Like those are of much use when you can turn from portrait to landscape.
> >
> > NOT a solution!
> 
> What for to set maximum size at all?

If you want to do that only for Freerunners, max(640,640) :)

Or you could query and place a max for the biggest on the dimensions.

Rui

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Nikita V. Youshchenko
> On Wed, Sep 16, 2009 at 04:13:16PM +0400, Nikita V. Youshchenko wrote:
> > > Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > > program specified minimum size: 198 by 350
> > > > > > > program specified maximum size: 198 by 350
> > > > > > > ...
> > > > > >
> > > > > > the way the contents are specified for the window, it isnt
> > > > > > resizable. the app
> > > > > > is in control of this.
> > > > >
> > > > > All SHR apps have these values defined as above.
> > > >
> > > > That means that all SHR apps will get non-resizable 198x350
> > > > windows under any stardards-compliant window manager.
> > > >
> > > > This is definitly a bug that should be fixed.
> > >
> > > and what is the proposed fix? Use XSetWMSizeHints?
> >
> > I've never written a line using E libraries, but quick search suggests
> > evas_object_size_hint_min_set() / evas_object_size_hint_max_set()
>
> Like those are of much use when you can turn from portrait to landscape.
>
> NOT a solution!

What for to set maximum size at all?


signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Rui Miguel Silva Seabra
On Wed, Sep 16, 2009 at 04:13:16PM +0400, Nikita V. Youshchenko wrote:
> > Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > program specified minimum size: 198 by 350
> > > > > > program specified maximum size: 198 by 350
> > > > > > ...
> > > > >
> > > > > the way the contents are specified for the window, it isnt
> > > > > resizable. the app
> > > > > is in control of this.
> > > >
> > > > All SHR apps have these values defined as above.
> > >
> > > That means that all SHR apps will get non-resizable 198x350 windows
> > > under any stardards-compliant window manager.
> > >
> > > This is definitly a bug that should be fixed.
> >
> > and what is the proposed fix? Use XSetWMSizeHints?
> 
> I've never written a line using E libraries, but quick search suggests 
> evas_object_size_hint_min_set() / evas_object_size_hint_max_set() 

Like those are of much use when you can turn from portrait to landscape.

NOT a solution!

Rui

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Nikita V. Youshchenko
> Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > program specified minimum size: 198 by 350
> > > > > program specified maximum size: 198 by 350
> > > > > ...
> > > >
> > > > the way the contents are specified for the window, it isnt
> > > > resizable. the app
> > > > is in control of this.
> > >
> > > All SHR apps have these values defined as above.
> >
> > That means that all SHR apps will get non-resizable 198x350 windows
> > under any stardards-compliant window manager.
> >
> > This is definitly a bug that should be fixed.
>
> and what is the proposed fix? Use XSetWMSizeHints?

I've never written a line using E libraries, but quick search suggests 
evas_object_size_hint_min_set() / evas_object_size_hint_max_set() 


signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Klaus 'mrmoku' Kurzmann
Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko:
> > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > program specified minimum size: 198 by 350
> > > > program specified maximum size: 198 by 350
> > > > ...
> > >
> > > the way the contents are specified for the window, it isnt resizable.
> > > the app
> > > is in control of this.
> >
> > All SHR apps have these values defined as above.
>
> That means that all SHR apps will get non-resizable 198x350 windows under
> any stardards-compliant window manager.
>
> This is definitly a bug that should be fixed.
and what is the proposed fix? Use XSetWMSizeHints? 

-- 

Klaus 'mrmoku' Kurzmann

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Nikita V. Youshchenko
> > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > program specified minimum size: 198 by 350
> > > program specified maximum size: 198 by 350
> > > ...
> >
> > the way the contents are specified for the window, it isnt resizable.
> > the app
> > is in control of this.
>
> All SHR apps have these values defined as above.

That means that all SHR apps will get non-resizable 198x350 windows under 
any stardards-compliant window manager.

This is definitly a bug that should be fixed.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Michal Brzozowski
2009/9/16 Carsten Haitzler 

> On Wed, 16 Sep 2009 12:00:33 +0200 Michal Brzozowski 
> said:
>
> > If the WM takes into account these values, you'll never be able to resize
> > the window. From my experience they don't depend on dpi.
> >
> > r...@om-gta02 ~ $ wmctrl -l
> > 0x0102  0 om-gta02 Notifier
> >
> > r...@om-gta02 ~ $ xprop -id 0x0102
> > ...
> > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > program specified minimum size: 198 by 350
> > program specified maximum size: 198 by 350
> > ...
>
> the way the contents are specified for the window, it isnt resizable. the
> app
> is in control of this.
>

All SHR apps have these values defined as above.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread The Rasterman
On Wed, 16 Sep 2009 12:00:33 +0200 Michal Brzozowski  said:

> If the WM takes into account these values, you'll never be able to resize
> the window. From my experience they don't depend on dpi.
> 
> r...@om-gta02 ~ $ wmctrl -l
> 0x0102  0 om-gta02 Notifier
> 
> r...@om-gta02 ~ $ xprop -id 0x0102
> ...
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
> program specified minimum size: 198 by 350
> program specified maximum size: 198 by 350
> ...

the way the contents are specified for the window, it isnt resizable. the app
is in control of this.

> 2009/9/16 arne anka 
> 
> > >> > evas_object_resize(win->win, 480, 600);
> > >> >
> > >> > is what we do.
> > >>
> > >> yepp. and it does not resize correetly on at least LXDE and apparently
> > >> IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx
> > >> 80x120).
> > >
> > > May this be dpi-related? Could you please try with different X server dpi
> > > settings?
> >
> > was one of the first ideas i got and tried already (with startx), but will
> > try again with "normal" X startup (nodm).
> > but i don't really believe it -- lxterminal frinst came up with a huge
> > font compared to "normal" startup, while messages still was the same size.
> >
> > ___
> > Openmoko community mailing list
> > community@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread The Rasterman
On Wed, 16 Sep 2009 11:28:18 +0200 "arne anka"  said:

> >> > evas_object_resize(win->win, 480, 600);
> >> >
> >> > is what we do.
> >>
> >> yepp. and it does not resize correetly on at least LXDE and apparently
> >> IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx
> >> 80x120).
> >
> > May this be dpi-related? Could you please try with different X server dpi
> > settings?
> 
> was one of the first ideas i got and tried already (with startx), but will  
> try again with "normal" X startup (nodm).
> but i don't really believe it -- lxterminal frinst came up with a huge  
> font compared to "normal" startup, while messages still was the same size.

it's simply that by default the window will be its minimum size given its
content unless sized to something else. illume with e will always maximize
windows (and dialogs get maximized horizontally but minimum size vertically,
centered over window). this is just the wm's policy. icewm, etc. etc. are not
implementing any "touchscreen small screen" policy. they implement a desktop
policy. you should expect this if you stick them on a smallscreen ts device
with no changes to their management policy.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Michal Brzozowski
If the WM takes into account these values, you'll never be able to resize
the window. From my experience they don't depend on dpi.

r...@om-gta02 ~ $ wmctrl -l
0x0102  0 om-gta02 Notifier

r...@om-gta02 ~ $ xprop -id 0x0102
...
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 198 by 350
program specified maximum size: 198 by 350
...

2009/9/16 arne anka 

> >> > evas_object_resize(win->win, 480, 600);
> >> >
> >> > is what we do.
> >>
> >> yepp. and it does not resize correetly on at least LXDE and apparently
> >> IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx
> >> 80x120).
> >
> > May this be dpi-related? Could you please try with different X server dpi
> > settings?
>
> was one of the first ideas i got and tried already (with startx), but will
> try again with "normal" X startup (nodm).
> but i don't really believe it -- lxterminal frinst came up with a huge
> font compared to "normal" startup, while messages still was the same size.
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread arne anka
>> > evas_object_resize(win->win, 480, 600);
>> >
>> > is what we do.
>>
>> yepp. and it does not resize correetly on at least LXDE and apparently
>> IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx
>> 80x120).
>
> May this be dpi-related? Could you please try with different X server dpi
> settings?

was one of the first ideas i got and tried already (with startx), but will  
try again with "normal" X startup (nodm).
but i don't really believe it -- lxterminal frinst came up with a huge  
font compared to "normal" startup, while messages still was the same size.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread Nikita V. Youshchenko
> > evas_object_resize(win->win, 480, 600);
> >
> > is what we do.
>
> yepp. and it does not resize correetly on at least LXDE and apparently
> IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx
> 80x120).

May this be dpi-related? Could you please try with different X server dpi 
settings?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-16 Thread arne anka
> evas_object_resize(win->win, 480, 600);
>
> is what we do.


yepp. and it does not resize correetly on at least LXDE and apparently  
IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx  
80x120).

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-15 Thread Klaus 'mrmoku' Kurzmann
Am Mittwoch 16 September 2009 00:22:04 schrieb Michal Brzozowski:
> 2009/9/15 jeremy jozwik 
>
> > On Tue, Sep 15, 2009 at 10:44 AM, arne anka  wrote:
> > >> [debian] shr-contacts/messages/dialer: window size and further issues
> > >
> > > no.
> > > if only debian it would have kept that to pkg-fso list.
> > > these apps are developed and mainly used on shr, so the shr guys are
> >
> > meant
> >
> > > as well -- and probably re the only one able to answer.
> >
> > right, but they work fine on the shr-distro. so this is not all
> > encompassing.
>
> This doesn't depend on the distro, but on the WM.
>
> I've had the same trouble when running these apps on SHR under Icewm. The
> problem is that they set a maximum size property (or something similar),
> and the WM won't resize them to anything bigger. The same thing happened in
> vala-terminal (except the other way around - too big and didn't fit the
> screen).
>
> Illume or enlightement seems to ignore these properties and set the size to
> 480x640 no matter what. So I did the same and hacked Icewm to ignore it and
> everything works fine.

evas_object_resize(win->win, 480, 600);

is what we do.
-- 

Klaus 'mrmoku' Kurzmann

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-15 Thread Michal Brzozowski
2009/9/15 jeremy jozwik 

> On Tue, Sep 15, 2009 at 10:44 AM, arne anka  wrote:
> >> [debian] shr-contacts/messages/dialer: window size and further issues
> >
> > no.
> > if only debian it would have kept that to pkg-fso list.
> > these apps are developed and mainly used on shr, so the shr guys are
> meant
> > as well -- and probably re the only one able to answer.
>
> right, but they work fine on the shr-distro. so this is not all
> encompassing.
>

This doesn't depend on the distro, but on the WM.

I've had the same trouble when running these apps on SHR under Icewm. The
problem is that they set a maximum size property (or something similar), and
the WM won't resize them to anything bigger. The same thing happened in
vala-terminal (except the other way around - too big and didn't fit the
screen).

Illume or enlightement seems to ignore these properties and set the size to
480x640 no matter what. So I did the same and hacked Icewm to ignore it and
everything works fine.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-15 Thread jeremy jozwik
On Tue, Sep 15, 2009 at 10:44 AM, arne anka  wrote:
>> [debian] shr-contacts/messages/dialer: window size and further issues
>
> no.
> if only debian it would have kept that to pkg-fso list.
> these apps are developed and mainly used on shr, so the shr guys are meant
> as well -- and probably re the only one able to answer.

right, but they work fine on the shr-distro. so this is not all encompassing.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-15 Thread arne anka
> [debian] shr-contacts/messages/dialer: window size and further issues

no.
if only debian it would have kept that to pkg-fso list.
these apps are developed and mainly used on shr, so the shr guys are meant  
as well -- and probably re the only one able to answer.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: shr-contacts/messages/dialer: window size and further issues

2009-09-15 Thread jeremy jozwik
On Tue, Sep 15, 2009 at 8:28 AM, arne anka  wrote:
> sebastian reichel made shr-messages/dialer/contacts available for debian
> and i decided to check them out.

[debian] shr-contacts/messages/dialer: window size and further issues

please.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


shr-contacts/messages/dialer: window size and further issues

2009-09-15 Thread arne anka
sebastian reichel made shr-messages/dialer/contacts available for debian  
and i decided to check them out.
i do not run illume, enlightment or whatever the name is, but LXDE.

when one of the apps mentioned above opens up its window is too small  
(about 80x120) and not resizable.
font size is ok, but frinst in dialer it's very cramped and in messages  
not everything is visible.

- how is the window size calculated?
- where can resizing be enabled?

while i am at it, that file
/etc/frameworkd-phonegui.conf
does it allow to configure anything else except

[phonegui]
library=libframeworkd-phonegui-efl.so.0

?

creating a new contact is nowhere visible stored --  
/etc/freesmartphone/opim/sqlite-contacts.db is not touched, though  
configured in /etc/frameworkd.conf.

and i just see, incoming messages are not notified (frameworkd prints  
something in its log, but ophonekitd doesn't).
is that a known problem? a missing config?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community