[RFC] Smallscreen mod for GtkFileChooser

[RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello openembedded-devel,

  I've prepared a patch to make GtkFileChooser, a
contemporary gtk's file open/save widget, to suite small, PDA-like
screens (including QVGA) better.

  The patch is available at
http://bugs.openembedded.org/show_bug.cgi?id=3634 , with extensive
description at
http://pfalcon-oe.blogspot.com/2008/01/smallscreen-mod-for-gtkfilechooser.html
. I'm glad I've written it in high detail, because Koen quickly
pointed me to similar patches in Poky:

http://svn.o-hand.com/view/poky?rev=3408&view=rev
http://svn.o-hand.com/view/poky?rev=2596&view=rev

  I didn't try them, but they appear to make more invasive changes to
gtk+, though apparently add more features (for good, bad, or for
vendor's requirements).

  So I'd like to ask for discussion of this situation, and deciding on
what version it would be better to import.


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: [RFC] Smallscreen mod for GtkFileChooser

[Florian Boor]

Hi,

Paul Sokolovsky schrieb:
>   I've prepared a patch to make GtkFileChooser, a
> contemporary gtk's file open/save widget, to suite small, PDA-like
> screens (including QVGA) better.

>   The patch is available at
> http://bugs.openembedded.org/show_bug.cgi?id=3634 , with extensive
> description at
> http://pfalcon-oe.blogspot.com/2008/01/smallscreen-mod-for-gtkfilechooser.html

Looks pretty good. I like the patch because it is not that intrusive.
If you could make all changes depend on the screen size it would be worth trying
to get it upstream. This might save us a lot of work in future.

> . I'm glad I've written it in high detail, because Koen quickly
> pointed me to similar patches in Poky:
> 
> http://svn.o-hand.com/view/poky?rev=3408&view=rev
> http://svn.o-hand.com/view/poky?rev=2596&view=rev
> 
>   I didn't try them, but they appear to make more invasive changes to
> gtk+, though apparently add more features (for good, bad, or for
> vendor's requirements).

Do we have a screenshot around to see how it looks? :)

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: [RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello Florian,

Monday, January 7, 2008, 6:51:34 PM, you wrote:

> Hi,

> Paul Sokolovsky schrieb:
>>   I've prepared a patch to make GtkFileChooser, a
>> contemporary gtk's file open/save widget, to suite small, PDA-like
>> screens (including QVGA) better.

>>   The patch is available at
>> http://bugs.openembedded.org/show_bug.cgi?id=3634 , with extensive
>> description at
>> http://pfalcon-oe.blogspot.com/2008/01/smallscreen-mod-for-gtkfilechooser.html

> Looks pretty good. I like the patch because it is not that intrusive.
> If you could make all changes depend on the screen size it would be worth trying
> to get it upstream. This might save us a lot of work in future.

  As Ross Burton of OpenedHand commented in my blog, they make steps
to upstream their changes, but of course that doesn't go smooth, it
takes time, refactors, waiting for new versions, etc. So, I'd prefer
to leave that to big guys, knowing that they care to make the future
bright. With my little-guy-who-scratches-his-and-fellow-users'-itches
hat on, I care about present being bright too, and sustainability of
the whole Linux-on-PDA effort. So, here's small patch optimized for a
given criteria (size), and I can maintain it in OE for now, even if
eventually it will be replaced by something else. In the meantime, I
have lotsa other patches ready, or in work, and working on them and
their upstreaming would be more beneficial imho.

  (Oh, and if someone has free big-guy-from-the-industry's hat, please
let me know ;-) ).

>> . I'm glad I've written it in high detail, because Koen quickly
>> pointed me to similar patches in Poky:
>> 
>> http://svn.o-hand.com/view/poky?rev=3408&view=rev
>> http://svn.o-hand.com/view/poky?rev=2596&view=rev
>> 
>>   I didn't try them, but they appear to make more invasive changes to
>> gtk+, though apparently add more features (for good, bad, or for
>> vendor's requirements).

> Do we have a screenshot around to see how it looks? :)

  I still didn't try it due to the above. I'd like first a confirmation
from Poky people that merging those patches to OE will be of benefit
to them (for example, wider testing). Then we can review the
functionality. I do worry a bit about QVGA support, as all latest OH
workings seems to be not optimized for it (Sato, Pimlico).

> Greetings

> Florian




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Smallscreen mod for GtkFileChooser

[Richard Purdie]

On Tue, 2008-01-08 at 16:34 +0200, Paul Sokolovsky wrote:
>   As Ross Burton of OpenedHand commented in my blog, they make steps
> to upstream their changes, but of course that doesn't go smooth, it
> takes time, refactors, waiting for new versions, etc. So, I'd prefer
> to leave that to big guys, knowing that they care to make the future
> bright. With my little-guy-who-scratches-his-and-fellow-users'-itches
> hat on, I care about present being bright too, and sustainability of
> the whole Linux-on-PDA effort. So, here's small patch optimized for a
> given criteria (size), and I can maintain it in OE for now, even if
> eventually it will be replaced by something else. In the meantime, I
> have lotsa other patches ready, or in work, and working on them and
> their upstreaming would be more beneficial imho.

It is something OpenedHand is working on and will continue to work on,
not least because maintaining a patch like that is painful. I can near
enough guarantee we will end up porting it to new gtk versions, I just
can't guarantee how quickly we'll do that.

>   (Oh, and if someone has free big-guy-from-the-industry's hat, please
> let me know ;-) ).
> 
> >> . I'm glad I've written it in high detail, because Koen quickly
> >> pointed me to similar patches in Poky:
> >> 
> >> http://svn.o-hand.com/view/poky?rev=3408&view=rev
> >> http://svn.o-hand.com/view/poky?rev=2596&view=rev
> >> 
> >>   I didn't try them, but they appear to make more invasive changes to
> >> gtk+, though apparently add more features (for good, bad, or for
> >> vendor's requirements).
> 
> > Do we have a screenshot around to see how it looks? :)
> 
>   I still didn't try it due to the above. I'd like first a confirmation
> from Poky people that merging those patches to OE will be of benefit
> to them (for example, wider testing). Then we can review the
> functionality. I do worry a bit about QVGA support, as all latest OH
> workings seems to be not optimized for it (Sato, Pimlico).

We're happy enough for wider testing. I can also confirm that patch
works well for QVGA. I'm not sure about screenshots but qemu poky images
are available from http://pokylinux.org/autobuild/poky/ and have a
screenshot utility! I would make one but I don't have a suitable image
handy :(.

Cheers,

Richard

Re: [RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello,

Tuesday, January 8, 2008, 6:49:01 PM, you wrote:

[]

>> > Do we have a screenshot around to see how it looks? :)
>> 
>>   I still didn't try it due to the above. I'd like first a confirmation
>> from Poky people that merging those patches to OE will be of benefit
>> to them (for example, wider testing). Then we can review the
>> functionality. I do worry a bit about QVGA support, as all latest OH
>> workings seems to be not optimized for it (Sato, Pimlico).

> We're happy enough for wider testing. I can also confirm that patch
> works well for QVGA. I'm not sure about screenshots but qemu poky images
> are available from http://pokylinux.org/autobuild/poky/ and have a
> screenshot utility! I would make one but I don't have a suitable image
> handy :(.


  We talked with Richard on IRC on how to proceed with this, and
decided that I'd try Poky's patches and see what they offer.

  Well, not much joy here. Here's screenshot (as installed under
Angstrom, I'm sorry beforehand if Poky is different):
http://linuxtogo.org/gowiki/PaulSokolovsky?action=AttachFile&do=view&target=Poky-smallscreen.png

  So, what we see is that the design of the dialog is changed,
simplifying it to just a file list, parent dir button, and buttons for
mounted filesystems (same icons appeared in Angstrom image). There're
still "desktop" gaps and dialog sizing (3/4 of screen width, no resize
with matchbox).

  Looking at the patches, there's filechooser-respect-style.patch,
whose name and quick scan suggests that at least gaps might be
configurable by theme, but we have what we have and OE's "standard"
themes like Clearlooks and GPE Default. Also, I'm not gtk+ styling
expert, but for me it looks like it just does different arithmetic
with the numbers hardcoded as they were before ;-(.

  Main patch is filechooser-default.patch, and its size (~200k for
gtk+ 2.10, ~400k for 2.12) and content suggests that it was an
implementation for older gtk+, or completely different code, so it
removes large content of pristine gtk+'s file and replaces it with
something else.


  I welcome different reviews, and I really, really would prefer that
smallscreen support in gtk+ was done, and maintained, past me, but
based on the above, and the current scope of this work (*1), I would
like to raise the original proposal: to apply my patch, at least to
Angstrom stable branch. Of course, I'd prefer .dev to keep in sync
too, but if there're concerns that applying such patch would lead to
false feeling that the issue is solved once and for all, and someone
plans to work on that soon, .dev can be skipped. Otherwise, it still
can be applied - we of course can shuffle and swap patches anytime the
changes are required.



*1) To make Angstrom work well now, and in sustainable manner (that includes
applying as little and as short patches as possible, which would do as
little as possible changes to the upstream, if the upstream can be made
well enough usable with such small changes.


> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Smallscreen mod for GtkFileChooser

[Richard Purdie]

Hi,

The reply below is from Tomas who wrote that patch and who isn't
subscribed here but is cc'd.

Richard

On Thu, 2008-01-10 at 11:19 +0200, Paul Sokolovsky wrote:
>   So, what we see is that the design of the dialog is changed,
> simplifying it to just a file list, parent dir button, and buttons for
> mounted filesystems 

This UI was designed for certain purposes; if someone can come with a
better UI for a small screen, by all means, but any additional element
added to the dialog is significantly impacting usuability due to the
visible file list shrinking (and I would be curious to know what is
missing there).

> (same icons appeared in Angstrom image).

If the icons are all the same, it is because the theme does not provide
icons for the particular media types; not the filechooser fault.

> There're still "desktop" gaps and dialog sizing (3/4 of screen width,
> no resize with matchbox).

The internal gaps of the filechooser were tweaked for a QVGA screen
(the gaps around the outside of the filechooser and the buttons are
consistent for all Gtk dialogs and would need to be patched elsewhere).

Overall, the dialog is as big as Gtk thinks it needs be; in that
particular screen shot it would benefit from being both wider (and
perhaps taller), but this is less of an issue on a landscape screen.

> Looking at the patches, there's filechooser-respect-style.patch,
> whose name and quick scan suggests that at least gaps might be
> configurable by theme, but we have what we have and OE's "standard"
> themes like Clearlooks and GPE Default. Also, I'm not gtk+ styling
> expert, but for me it looks like it just does different arithmetic
> with the numbers hardcoded as they were before ;-(.

The respect-style patch does two things: (a) it removes the set_style()
virtual function that was preventing styling via theme; (b) it adjust
some of the geometry to reduce space waste (BTW, this patch is no longer
present in 2.12.x patch set, the geometry might need to be tweaked a
bit).

>   Main patch is filechooser-default.patch, and its size (~200k for
> gtk+ 2.10, ~400k for 2.12) and content suggests that it was an
> implementation for older gtk+, or completely different code, so it
> removes large content of pristine gtk+'s file and replaces it with
> something else.

Yep, that was initially a patch for 2.6, ported up to 2.10 (the size of
the patch is due to the fact that I have removed as much of the dead
code as possible). For 2.12 I have just replaced the
gtkfilechooserdefault.c file with the patched one from 2.10, as the
gtkfilechooserdefault is increasing developing in ways that are not
really beneficial for the embedded use, and a complete replacement is
needed.

(The patches also add functionality, notably the root-folder property
that makes it possible to specify that the user should not be able to
descent below certain location in the fs tree.)

> *1) To make Angstrom work well now, and in sustainable manner (that includes
> applying as little and as short patches as possible, which would do as
> little as possible changes to the upstream, if the upstream can be made
> well enough usable with such small changes.

In this case, this is a false premise; the default gtk filechooser is
unsuitable for embedded HW, and an ever increasing portion of its code
is related to features that just cannot be easily used on a small screen
(most of it really: bookmarks, recent files, the wretched navigation
bar). IMO, a small patch is not a viable long-term solution. It would be
ideal if an alternate implementation for GtkFileChooserDefault could be
pushed into Gtk and could be enabled via a configure option (something
like --enable-embedded-tweaks), but I gathered that this is unlikely to
happen.

Tomas

Re: [RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello Richard,

Thursday, January 10, 2008, 12:30:08 PM, you wrote:

> Hi,

> The reply below is from Tomas who wrote that patch and who isn't
> subscribed here but is cc'd.

> Richard

  Thanks for the reply, Tomas! To not write too much, I'll answer on
paradigmatic/organizational points only, as technical depends on them
here.

> On Thu, 2008-01-10 at 11:19 +0200, Paul Sokolovsky wrote:
>>   So, what we see is that the design of the dialog is changed,
>> simplifying it to just a file list, parent dir button, and buttons for
>> mounted filesystems 

> This UI was designed for certain purposes; if someone can come with a
> better UI for a small screen, by all means, but any additional element
> added to the dialog is significantly impacting usuability due to the
> visible file list shrinking (and I would be curious to know what is
> missing there).

  That's what I thought too after looking close at it. If I was UI
designer for a consumer, mass-market oriented device, I would come up
with a similar design - light and not distracting a user with many
features. If I were manager for such project, I would approve it for
implementation, and if I were programmer, I would implement it without
making faces ;-).

  But OE is different story.. And it seems that these patches fall
into "not directly mergeable from Poky" category. It would be nice if
we could settle on this, as I really don't want to seem like I sat in
the corner, missed happenings around, and now push my piece out of
stubbornness. This is not first and not last case when Poky's stuff
can't be merged, including cases which I regret much more (e.g.,
formfactor package). It doesn't diminish the fact that there's great
exchange between Poky and OE otherwise.

>> (same icons appeared in Angstrom image).

> If the icons are all the same, it is because the theme does not provide
> icons for the particular media types; not the filechooser fault.

>> There're still "desktop" gaps and dialog sizing (3/4 of screen width,
>> no resize with matchbox).

> The internal gaps of the filechooser were tweaked for a QVGA screen
> (the gaps around the outside of the filechooser and the buttons are
> consistent for all Gtk dialogs and would need to be patched elsewhere).

> Overall, the dialog is as big as Gtk thinks it needs be; in that
> particular screen shot it would benefit from being both wider (and
> perhaps taller), but this is less of an issue on a landscape screen.

>> Looking at the patches, there's filechooser-respect-style.patch,
>> whose name and quick scan suggests that at least gaps might be
>> configurable by theme, but we have what we have and OE's "standard"
>> themes like Clearlooks and GPE Default. Also, I'm not gtk+ styling
>> expert, but for me it looks like it just does different arithmetic
>> with the numbers hardcoded as they were before ;-(.

> The respect-style patch does two things: (a) it removes the set_style()
> virtual function that was preventing styling via theme; (b) it adjust
> some of the geometry to reduce space waste (BTW, this patch is no longer
> present in 2.12.x patch set, the geometry might need to be tweaked a
> bit).

>>   Main patch is filechooser-default.patch, and its size (~200k for
>> gtk+ 2.10, ~400k for 2.12) and content suggests that it was an
>> implementation for older gtk+, or completely different code, so it
>> removes large content of pristine gtk+'s file and replaces it with
>> something else.

> Yep, that was initially a patch for 2.6, ported up to 2.10 (the size of
> the patch is due to the fact that I have removed as much of the dead
> code as possible). For 2.12 I have just replaced the
> gtkfilechooserdefault.c file with the patched one from 2.10, as the
> gtkfilechooserdefault is increasing developing in ways that are not
> really beneficial for the embedded use, and a complete replacement is
> needed.

> (The patches also add functionality, notably the root-folder property
> that makes it possible to specify that the user should not be able to
> descent below certain location in the fs tree.)

  Heh, I tried to follow code to make sure there was no typo there: I
would think it would be more natural to limit user to chroot-like
scheme, to "help" one organize files (make sure one cannot drop files
around the entire system and possibly have troubles to find them later).

  PocketPC/WindowsMobile employs such scheme - limits standard apps to
"My documents" directory and at most to a one subdir level under it.
Fully practical and streamlining for users who treat a device like
"organizer", but limiting for users who'd like to see it as
"a computer in a pocket". (Not arguing anything here, just point that
different vendors make different choices, which are easily understood
within the target purpose, while couldn't make everyone happy).

>> *1) To make Angstrom work well now, and in sustainable manner (that includes
>> applying as little and as short patches as possible, which would do as
>> little as possible changes to the upstream, if the upstream can be made
>> well enough usable with such small changes.

> In this case, this is a false premise; the default gtk filechooser is
> unsuitable for embedded HW, and an ever increasing portion of its code
> is related to features that just cannot be easily used on a small screen
> (most of it really: bookmarks, recent files, the wretched navigation
> bar).

  We go to "opinions-opinions" land here. Few people commented on
screenshot of my patch, and everyone has different suggestions for
improvements. But my patch explicitly skips this route. It treats
GtkFileChooserDefault as what it is - the official upstream widget. It
doesn't care if it's good or bad, it adapts it for environment which
was overlooked during GtkFileChooser design/implementation. In this
regard, it does as minimal changes to look and feel, as possible.
Expressed numerically (if we had quantitative criteria for look&feel
changes), those would be below 10% of changes.

  Now if you want *my* opinion, bookmarks are really useful. I don't
really use them much on desktop, but they should streamline on-spot UI
interaction with handheld device. Just think that your showing mounted
FSs is kind of bookmarks, but hardcoded. Now, upstream bookmarks allow
users to create bookmarks per their likes and needs. Of course, paned
UI for this is not ideal. In a comment to my blog, Stanislav Brabec
wrote he imagines wizard-like UI for that, when user first chooses
bookmark (or root/current dir, apparently), and then shown filelist. I
would think that having dropdown button in the single dialog would be
better.

  As for navigation bar, fully agree. Someone really went out of his
way to create "now, something different" ;-). (And just don't tell me
its rooted in MacOS again).

> IMO, a small patch is not a viable long-term solution. It would be
> ideal if an alternate implementation for GtkFileChooserDefault could be
> pushed into Gtk and could be enabled via a configure option (something
> like --enable-embedded-tweaks), but I gathered that this is unlikely to
> happen.

  Not by me, or rather, not this time. And it's not about
wanna/dont-wanna, it's about good self-consciousness ;-). Being a
volunteer contributor to OE, I don't have resources or even grounds to
come up with upstream-suitable solution. Just to get grounds, I would
need to review existing solutions, communicate with authors of
existing solutions, provide RFCs and designs suitable for all, or
many, of them. I don't have resources for that too. So, giving way to
you, gentlemen ;-).

  Besides, if I'd get on gtk+ upstream, I'd have to start from the
start, with things like http://bugzilla.gnome.org/show_bug.cgi?id=129463 .
But look, people before me tried all methods, including such:
http://bugzilla.gnome.org/show_bug.cgi?id=129463#c40 . Of no avail.
They still ship glorious UI bugs straight into users' face ;-)).

> Tomas




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Florian Boor]

Hi,

Paul Sokolovsky schrieb:
>   Well, not much joy here. Here's screenshot (as installed under
> Angstrom, I'm sorry beforehand if Poky is different):
> http://linuxtogo.org/gowiki/PaulSokolovsky?action=AttachFile&do=view&target=Poky-smallscreen.png
> 
>   So, what we see is that the design of the dialog is changed,
> simplifying it to just a file list, parent dir button, and buttons for
> mounted filesystems (same icons appeared in Angstrom image). There're
> still "desktop" gaps and dialog sizing (3/4 of screen width, no resize
> with matchbox).

The screenshot pretty much indicates that the default Gnome spacing wastes too
much of space and looks ugly on these small screens. In fact I would make this
window fullscreen on such a small screen. This dialog style does not make much
of sense and only reduces usability. Just keep in mind that a file selector is
usually a window that displays a lot of information at one time and needs all
the space it can get.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Joaquim Duran]

En/na Florian Boor ha escrit:
> Hi,
> 
> Paul Sokolovsky schrieb:
>>   Well, not much joy here. Here's screenshot (as installed under
>> Angstrom, I'm sorry beforehand if Poky is different):
>> http://linuxtogo.org/gowiki/PaulSokolovsky?action=AttachFile&do=view&target=Poky-smallscreen.png
>>
>>   So, what we see is that the design of the dialog is changed,
>> simplifying it to just a file list, parent dir button, and buttons for
>> mounted filesystems (same icons appeared in Angstrom image). There're
>> still "desktop" gaps and dialog sizing (3/4 of screen width, no resize
>> with matchbox).
> 
> The screenshot pretty much indicates that the default Gnome spacing wastes too
> much of space and looks ugly on these small screens. In fact I would make this
> window fullscreen on such a small screen. This dialog style does not make much
> of sense and only reduces usability. Just keep in mind that a file selector is
> usually a window that displays a lot of information at one time and needs all
> the space it can get.
> 
> Greetings
> 
> Florian
> 

Is it possible only apply the patch if GUI_MACHINE_CLASS = "smallscreen"
is set?

Thanks and Best Regards,
Joaquim Duran

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Florian Boor]

Hi,

Joaquim Duran schrieb:
> Is it possible only apply the patch if GUI_MACHINE_CLASS = "smallscreen"
> is set?

in theory yes, but that makes your GTK package specific for each device. It
would be better if the screen size is checked at runtime. Ideally GTK would do
this once and adjust spacing definitions that can be used by GTK implementation
and applications. libgpewidget does it in this way too.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Joaquim Duran]

En/na Florian Boor ha escrit:
> Hi,
> 
> Joaquim Duran schrieb:
>> Is it possible only apply the patch if GUI_MACHINE_CLASS = "smallscreen"
>> is set?
> 
> in theory yes, but that makes your GTK package specific for each device. It
> would be better if the screen size is checked at runtime. Ideally GTK would do
> this once and adjust spacing definitions that can be used by GTK implementation
> and applications. libgpewidget does it in this way too.
> 
> Greetings
> 
> Florian
> 

OK, I see.

Joaquim Duran

problem when i compile image

[ohviey1]

There is a problem when i try to contact this server how can i solve?
> http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.3.tar.bz2
>
>
>   

Re: problem when i compile image

[pHilipp Zabel]

On Jan 11, 2008 9:16 AM, ohviey1 <stefano.regno@spesonline.com> wrote:
>
>
> There is a problem when i try to contact this server how can i solve?
> > http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.3.tar.bz2

Try again later or check whether you are behind weird proxies or look
at the traceroute to xorg.freedesktop.org.
The server is up and I can download that file without problems.

regards
Philipp

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello Florian,

Thursday, January 10, 2008, 2:28:06 PM, you wrote:

> Hi,

> Joaquim Duran schrieb:
>> Is it possible only apply the patch if GUI_MACHINE_CLASS = "smallscreen"
>> is set?

   Note that the patch is helpful for "bigscreen" devices in OE too
;-).

> in theory yes, but that makes your GTK package specific for each device.

  Yes, and that's bad. But we don't *have to* apply it selectively. As
I tried to describe it in blog, and elaborated in the other mail, I
deliberately made as little as possible appearance and behavior
changes to the dialog. If you'll run it on large screen, the only
change you will notice is that it has a smaller gaps and margins. It
is fully usable otherwise.

  Maybe even that could be elaborated, but note that we apply many
"worse" patches to gtk+ in OE already. Consider disable-tooltips.patch.
It cuts off tooltips unconditionally. Run with mouse? Sorry. Not that
current Angstrom's xserver-kdrive setup allows to run with mouse at
all... etc, etc. No worries, all those issues are on my todo list. And
the sooner we finish with the current issue, the sooner I'll be able
to get to them.

> It
> would be better if the screen size is checked at runtime.

  So, that's what my patch does.

> Ideally GTK would do
> this once and adjust spacing definitions that can be used by GTK implementation
> and applications.

  And here where caveat comes - think about screen rotation. Think
about changing resolutions. Think about these actions happening while
dialog is on screen...

> libgpewidget does it in this way too.

> Greetings

> Florian




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Florian Boor]

Hi,

Paul Sokolovsky schrieb:
>   And here where caveat comes - think about screen rotation. Think
> about changing resolutions. Think about these actions happening while
> dialog is on screen...

I would not say this - it would be a major improvement over the current -
completely static - spacing. Of course these situations can occur, but that's
not the average user faces every day. Proper handling of changing display
parameters is completely different and much more intrusive topic.


Greetings

Florian


-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello Florian,

Thursday, January 10, 2008, 7:11:20 PM, you wrote:

> Hi,

> Paul Sokolovsky schrieb:
>>   And here where caveat comes - think about screen rotation. Think
>> about changing resolutions. Think about these actions happening while
>> dialog is on screen...

> I would not say this - it would be a major improvement over the current -
> completely static - spacing. Of course these situations can occur, but that's
> not the average user faces every day. Proper handling of changing display
> parameters is completely different and much more intrusive topic.

  Fully agree, and that was just to again show that there're many
issues towards ideal PDA support in gtk, and small guys would have
hard time trying to solve it. Upstream itself, having resource and
knowledge, should lead that movement, with support of parties having
enough resources to push the process.

  But we don't have to wait for perfect solution either - we can
start improving usability now, even if that work will be superceded in
the end ;-I. Who will win are users, who will be able to use Linux-on-PDA
right now, and community, which will be growing with these happy users,
while the Linux industry keeps improving to offer even greater stuff.

> Greetings

> Florian





-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Smallscreen mod for GtkFileChooser

[Michael 'Mickey' Lauer]

Paul Sokolovsky wrote:
> I would
> like to raise the original proposal: to apply my patch, at least to
> Angstrom stable branch.
>  Of course, I'd prefer .dev to keep in sync
> too, but if there're concerns that applying such patch would lead to
> false feeling that the issue is solved once and for all, and someone
> plans to work on that soon, .dev can be skipped. Otherwise, it still
> can be applied - we of course can shuffle and swap patches anytime the
> changes are required.

I'm +1 for applying it to both branches. At the end of the day, it
"fixes" the issue in the best way for now. We can always improve
later.

Regards,

:M:

-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [Angstrom-devel] [RFC] Smallscreen mod for GtkFileChooser

[Paul Sokolovsky]

Hello Michael,

Thursday, January 10, 2008, 1:08:41 PM, you wrote:

> Paul Sokolovsky wrote:
>> I would
>> like to raise the original proposal: to apply my patch, at least to
>> Angstrom stable branch.
>>  Of course, I'd prefer .dev to keep in sync
>> too, but if there're concerns that applying such patch would lead to
>> false feeling that the issue is solved once and for all, and someone
>> plans to work on that soon, .dev can be skipped. Otherwise, it still
>> can be applied - we of course can shuffle and swap patches anytime the
>> changes are required.

> I'm +1 for applying it to both branches. At the end of the day, it
> "fixes" the issue in the best way for now. We can always improve
> later.

  Thanks, committed to both!

> Regards,

> :M:




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com