Hi, couple of comments to the color pickers...
>http://zwong.de/wp-content/uploads/2009/10/screenshot12.png
Having a pre-defined palette (and possibly a picker to choose different
palettes) seems like the best way to tackle this.
Maybe just start with "Tango palette" (as proposed) and "user-def
2009/10/1 Cornelius Hald :
>> I have created a small mockup of a possible
>> HildonExtrasColorChooserDialog. It uses a view in Edit mode (is that the
>> correct term?) to be able to fit the colorwheel in the screen without
>> making it too small. On the left, there is space for the six last used
>>
Hi Andrew!
> Thanks for the comments. I would have posted screenshots, but things
> look a bit weird in scratchbox sometimes and I have no access to a device.
No problem, I know the sometimes rather ugly output of scratchbox :)
> I agree with all your comments, all of which I feel would be
>
Conny,
Thanks for the comments. I would have posted screenshots, but things
look a bit weird in scratchbox sometimes and I have no access to a device.
I agree with all your comments, all of which I feel would be
implementable. Getting the label onto the button is something I
definitely want,
Hi Andrew,
> I have released countdown-home 0.5-8 to extras-testing for Fremantle. I
> have gotten some initial positive feedback for the colour and font
> selection I use.
I tried your applet and the dialogs are working good and they are finger
friendly. Two things the deprecated dialogs are
Hi Felipe,
> I have created a small mockup of a possible
> HildonExtrasColorChooserDialog. It uses a view in Edit mode (is that the
> correct term?) to be able to fit the colorwheel in the screen without
> making it too small. On the left, there is space for the six last used
> colors. On the righ
On Wed, 2009-09-30 at 18:24 +0200, Thomas Perl wrote:
> Why don't we simply create a new library and be done with it? That
> library can be published to Extras through the usual means, and apps
> that depend on it will automatically install it when needed.
Amen :)
> This thread has gone for two d
El jue, 01-10-2009 a las 13:46 +0200, Murray Cumming escribió:
> And it assumes that trying to put widgets
> directly into hildon will magically improve them, maybe by therefore
> forcing hildon developers to work them. But that won't work - they
> will just rot there and eventually be removed.
I
On Thu, 2009-10-01 at 11:11 +0100, Graham Cobb wrote:
> On Thursday 01 October 2009 10:16:56 Murray Cumming wrote:
> > I don't see any need whatsoever to fork hildon. It's just an invitation
> > to confusion and nasty problems such as this.
> >
> > If someone wants to create a reusable set of widge
On Thursday 01 October 2009 10:16:56 Murray Cumming wrote:
> I don't see any need whatsoever to fork hildon. It's just an invitation
> to confusion and nasty problems such as this.
>
> If someone wants to create a reusable set of widgets, they should just
> create a new library. It's not difficult.
On Wed, 2009-09-30 at 14:10 +0300, Marius Vollmer wrote:
> ext Alberto Garcia writes:
>
> > On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote:
> >
> >> > we can perfectly create a parallel installable version of the
> >> > same library, that the community can maintain in extras and l
2009/9/30 Marius Vollmer :
> "Hamalainen Kimmo (Nokia-D/Helsinki)"
> writes:
>
>> On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
>> wrote:
>>> "Hamalainen Kimmo (Nokia-D/Helsinki)"
>>> writes:
>>>
>>> > What prevents the community from releasing this "unstable" libhildon
>>>
El mié, 30-09-2009 a las 14:10 +0300, Marius Vollmer escribió:
> ext Alberto Garcia writes:
>
> > On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote:
> >
> >> > we can perfectly create a parallel installable version of the
> >> > same library, that the community can maintain in extras
"Hamalainen Kimmo (Nokia-D/Helsinki)"
writes:
> On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
> wrote:
>> "Hamalainen Kimmo (Nokia-D/Helsinki)"
>> writes:
>>
>> > What prevents the community from releasing this "unstable" libhildon
>> > before Nokia does the "stable" rele
ext Alberto Garcia writes:
> On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote:
>
>> > we can perfectly create a parallel installable version of the
>> > same library, that the community can maintain in extras and link
>> > against in their applications.
>>
>> Yes, but there are som
> On Wed, September 30, 2009 10:47, Andrew Flegg wrote:
> > On Wed, Sep 30, 2009 at 05:25, wrote:
>
> > Given the speed around which the colour picker discussions settled
> > down, and the fact it will iterate quickly once actually being used in a
> > real world app, I can't imagine working in up
On Wed, September 30, 2009 10:47, Andrew Flegg wrote:
> On Wed, Sep 30, 2009 at 05:25, wrote:
> Given the speed around which the colour picker discussions settled
> down, and the fact it will iterate quickly once actually being used in a
> real world app, I can't imagine working in upstream libh
On Wed, Sep 30, 2009 at 05:25, wrote:
>>
>> Is there any reason to suspect that the situation will be different
>> with Fremantle once Maemo Devices is pushing for Harmattan?
>
> Yes, there are reasons that come to mind:
>
> - Hildon is a library. [...]
> - App Manager Diablo [is not comparable]
On Wed, September 30, 2009 10:12, Kimmo Hämäläinen wrote:
> On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
> wrote:
>> Right now, we have a very strict division between packages that are
>> released by Nokia, and the rest. You can not update a Nokia package from
>> the outsid
On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
wrote:
> "Hamalainen Kimmo (Nokia-D/Helsinki)"
> writes:
>
> > What prevents the community from releasing this "unstable" libhildon
> > before Nokia does the "stable" release?
>
> The unstable release would not be of much use s
> > I agree. Maybe I'm wrong but I think Hildon updates are possible in
> > Fremantle. As long as the new widgets make sense, the patches are good and
> > they are well tested by the community and don't introduce risks or
> > regressions... Why not?
>
> Because there's a perceived *risk* of risks &
On Tue, Sep 29, 2009 at 11:39:37PM +0300, Claudio Saavedra wrote:
> > The first obvious problem is that we would end up having two
> > similar versions of the same library installed, and that
> > means more disk and memory, apart from the inability to use
> > maemo-launcher.
>
> Can you elaborate
El mar, 29-09-2009 a las 18:41 +0200, Alberto Garcia escribió:
> On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote:
>
> > > we can perfectly create a parallel installable version of the
> > > same library, that the community can maintain in extras and link
> > > against in their appli
Hi,
I have created a small mockup of a possible
HildonExtrasColorChooserDialog. It uses a view in Edit mode (is that the
correct term?) to be able to fit the colorwheel in the screen without
making it too small. On the left, there is space for the six last used
colors. On the right, the use can ad
On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote:
> > we can perfectly create a parallel installable version of the
> > same library, that the community can maintain in extras and link
> > against in their applications.
>
> Yes, but there are some practical problems about that.
The
On Tue, Sep 29, 2009 at 06:19:04PM +0200, Javier Jardón wrote:
> > Hildon could perfectly move forward, with new widgets and all the
> > bug fixes that the community wants to see. If Nokia doesn't react
> > to that, we can perfectly create a parallel installable version of
> > the same library, th
2009/9/29 Claudio Saavedra :
> Hildon could perfectly move forward, with new widgets and all the bug
> fixes that the community wants to see. If Nokia doesn't react to that,
> we can perfectly create a parallel installable version of the same
> library, that the community can maintain in extras and
ext Claudio Saavedra writes:
> Well, that's too much of tinkering with libraries when this is not a
> library issue, but a distribution problem. Maemo is a distribution and
> has a problem. It needs to be fixed at the distribution level.
I agree.
> Hildon could perfectly move forward, with new
On Tue, Sep 29, 2009 at 15:18, wrote:
>> No, you are right, it should not be hard to accept contributions to
>> libhildon.
>
> I agree. Maybe I'm wrong but I think Hildon updates are possible in
> Fremantle. As long as the new widgets make sense, the patches are good and
> they are well tested by
"Hamalainen Kimmo (Nokia-D/Helsinki)"
writes:
> What prevents the community from releasing this "unstable" libhildon
> before Nokia does the "stable" release?
The unstable release would not be of much use since people can not
easily install it on their devices.
Right now, we have a very strict
> No, you are right, it should not be hard to accept contributions to
> libhildon.
I agree. Maybe I'm wrong but I think Hildon updates are possible in Fremantle.
As long as the new widgets make sense, the patches are good and they are well
tested by the community and don't introduce risks or reg
El mar, 29-09-2009 a las 16:54 +0300, Marius Vollmer escribió:
>
>
> > If there really is a problem then there is only one other
> alternative I see:
> > work in Hildon (or a fork) and allow the community to release an
> alternative
> > to the standard hildon libraries (under a different librar
Hi all,
I have released countdown-home 0.5-8 to extras-testing for Fremantle. I
have gotten some initial positive feedback for the colour and font
selection I use.
I have made the font selection and colour selection widgets as
self-contained as possible - they are not integrated in any way in
On Tue, 2009-09-29 at 14:49 +0200, Vollmer Marius (Nokia-D/Helsinki)
wrote:
> ext Claudio Saavedra writes:
>
> > To be realistic, I don't think you'll have your library ready by the
> > time Fremantle ships either, so I don't see that as a real problem.
>
> The problem is that after Fremantle sh
can i have a recap
from what i know now,
there are 2 sortof nearly good finger friendly color selection dialog tests
in use
in two different apps and some python test code
all of which is better than the not very finger friendly but standard
implementations.
we now seem to have stopped dead with
ext Graham Cobb writes:
> Due to the signing stuff the community cannot replace
> Hildon even if we wanted to.
You can: create a package called libhildon-community (or similar) and
have it Conflict, Replace, and Provide libhildon1. Then the Application
manager should allow it to be installed a
On Tuesday 29 September 2009 13:49:10 Marius Vollmer wrote:
> ext Claudio Saavedra writes:
> > To be realistic, I don't think you'll have your library ready by the
> > time Fremantle ships either, so I don't see that as a real problem.
>
> The problem is that after Fremantle ships, libhildon is fr
ext Claudio Saavedra writes:
> To be realistic, I don't think you'll have your library ready by the
> time Fremantle ships either, so I don't see that as a real problem.
The problem is that after Fremantle ships, libhildon is frozen for a
long time. It is prudent to assume that there will be no
On Tue, 2009-09-29 at 15:11 +0300, Claudio Saavedra wrote:
> > Input from Nokia would be very welcome (and in my new role I will be asking
> > for some). However, I am sure that there is no way that any more widgets
> > are
> > going to be added to Hildon before Fremantle ships.
>
> To be real
On Tue, Sep 29, 2009 at 13:11, Claudio Saavedra wrote:
>
[big snip of lot's of sensible stuff]
>
> I don't see the need to divert before even attempting to join the
> project.
I think the chance of Nokia shipping an updated libhildon, containing
community widgets, during Fremantle's *lifetime* is
El mar, 29-09-2009 a las 12:51 +0100, Graham Cobb escribió:
> On Tuesday 29 September 2009 11:39:05 Claudio Saavedra wrote:
> > If you avoid having symbol clashing by using a different name for the
> > widgets in the hypotetical library, if/when these go into hildon you'll
> > have to deprecate the
On Tuesday 29 September 2009 11:39:05 Claudio Saavedra wrote:
> If you avoid having symbol clashing by using a different name for the
> widgets in the hypotetical library, if/when these go into hildon you'll
> have to deprecate them and still carry them around for people without
> time to migrate t
El mar, 29-09-2009 a las 11:11 +0100, Graham Cobb escribió:
>
> So, I agree that a real community library is a better solution,
> although it has its own problems with maintenance (particularly for
> widgets which do get adopted by Hildon but with some changes). But at
> least they can be solved
On Tue, 2009-09-29 at 12:43 +0300, Claudio Saavedra wrote:
> El lun, 28-09-2009 a las 15:08 +0100, Graham Cobb escribió:
> > why not develop them initially as pieces of standalone code that
> > people include (as source code) into their projects to use, for now?
>
> Have you heard of libegg? If yo
On Tuesday 29 September 2009 10:43:20 Claudio Saavedra wrote:
> El lun, 28-09-2009 a las 15:08 +0100, Graham Cobb escribió:
> > why not develop them initially as pieces of standalone code that
> > people include (as source code) into their projects to use, for now?
>
> Have you heard of libegg? If
El lun, 28-09-2009 a las 15:08 +0100, Graham Cobb escribió:
> why not develop them initially as pieces of standalone code that
> people include (as source code) into their projects to use, for now?
Have you heard of libegg? If you haven't, I'd suggest you to go google
for discussions on its exista
On Mon, 2009-09-28 at 16:17 +0200, Cornelius Hald wrote:
> Well, HildonColorChooser and GtkColorSelection already have totally
> different API. So I wouldn't even know which one of them to emulate.
> Also Hildon and Gtk will still be around, so we can't develop a drop-in
> replacement because the n
> I'm not completely sure what you're asking :) Could you
> elaborate a bit
> please.
>
> well, a simple dialog is one thing and thats what we appear to be
> rounding on now.
>
> but I'm sure over the years in the main libraries, options and flags
> and extra bits have b
On Monday 28 September 2009 14:48:01 Cornelius Hald wrote:
> On Mon, 2009-09-28 at 13:28 +, gary liquid wrote:
> > do we attempt to make sure the api/options for a gtk/hildon/sexy lib
> > replacement exist, or do we aim for a maemo_community library for
> > these kinds of dialogs?
>
> I'm not c
On Mon, Sep 28, 2009 at 1:48 PM, Cornelius Hald wrote:
> On Mon, 2009-09-28 at 13:28 +, gary liquid wrote:
> > for now, sure its the only practical way we are going to advance
> > since we have a good idea what this may look like, how about we get
> > down to sorting out where its going to li
On Mon, 2009-09-28 at 13:28 +, gary liquid wrote:
> for now, sure its the only practical way we are going to advance
> since we have a good idea what this may look like, how about we get
> down to sorting out where its going to live.
I was hoping that we get some input from the Hildon project
On Mon, 2009-09-28 at 15:29 +0200, Thomas Perl wrote:
> 2009/9/28 Cornelius Hald :
> > On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
> >> * Added pure black and white as suggested by Graham
> >> * One slot is free (when the current setting is a custom color that is
> >>not in the pale
2009/9/28 Cornelius Hald :
> On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
>> * Added pure black and white as suggested by Graham
>> * One slot is free (when the current setting is a custom color that is
>> not in the palette, the slot will be taken by that color and pre-selected)
>
>
On Mon, Sep 28, 2009 at 1:17 PM, Cornelius Hald wrote:
> On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
> > 2009/9/28 Cornelius Hald :
> > > On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
> > >> Yes, we can probably add whatever we want in the "Advanced" color
> > >> dialog. One thi
On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
> 2009/9/28 Cornelius Hald :
> > On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
> >> Yes, we can probably add whatever we want in the "Advanced" color
> >> dialog. One thing that I would find nice (and that I have not found on
> >> any pl
2009/9/28 Cornelius Hald :
> On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
>> Yes, we can probably add whatever we want in the "Advanced" color
>> dialog. One thing that I would find nice (and that I have not found on
>> any platform yet) is that customized colors are saved per-user and not
On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
> Yes, we can probably add whatever we want in the "Advanced" color
> dialog. One thing that I would find nice (and that I have not found on
> any platform yet) is that customized colors are saved per-user and not
> per-application (so that when
2009/9/28 Piñeiro :
> From: Thomas Perl
>> I'd rather do without the scrolling if possible. Here's my mock-up and the
>> accompanying Python script that you can use to try it out:
>>
>> http://thpinfo.com/2009/maemo/colorchooser.png
>>
>> http://thpinfo.com/2009/maemo/colorchooser.py
>
> It looks
From: Thomas Perl
> 2009/9/26 Cornelius Hald :
> > So how about a dialog that just shows n rows with 3 to 4 colors in each
> > row. Those rows are in a panable area so it's easy to scroll them. Those
> > colors are taken from a palette and (maybe) colors that have been
> > selected in the advance
On Sun, 2009-09-27 at 16:17 +, gary liquid wrote:
> how about getting rid of the borders and make it a more varied
> palette?
>
> a bright vibrant rainbow
I think it's better to have the colors separated like it is in Thomas
demo. The simple reason is, that sometimes you want to select the sa
On Sat, 2009-09-26 at 16:00 +0200, Thomas Perl wrote:
> I'd rather do without the scrolling if possible. Here's my mock-up and the
> accompanying Python script that you can use to try it out:
>
> http://thpinfo.com/2009/maemo/colorchooser.png
>
> http://thpinfo.com/2009/maemo/colorchooser.py
Ver
hehe
it was a very short enthusiastic message
having the dual level dialog with easy colours on the front and an advanced
button where we can use more fiddly configuration seems the nicest way.
how the eventual dialog looks is not important to me, its the principle that
matters.
it allows a user
On Sunday 27 September 2009 10:13:57 Thomas Perl wrote:
> We might also go and have some pre-defined palettes that the developer can
> choose when using the dialog (say, one wants to use the Tango colors, one
> wants to use more strongly constrasting colors and another one might just
> want to use
2009/9/26 Graham Cobb :
> On Saturday 26 September 2009 15:00:33 Thomas Perl wrote:
>> I'd rather do without the scrolling if possible. Here's my mock-up and the
>> accompanying Python script that you can use to try it out:
>
> I like the approach. Good demo!
>
> I am not sure about the particular
On Saturday 26 September 2009 15:00:33 Thomas Perl wrote:
> I'd rather do without the scrolling if possible. Here's my mock-up and the
> accompanying Python script that you can use to try it out:
I like the approach. Good demo!
I am not sure about the particular colours: it seems to be missing a
On Sat, Sep 26, 2009 at 2:00 PM, Thomas Perl wrote:
> 2009/9/26 Cornelius Hald :
> > So how about a dialog that just shows n rows with 3 to 4 colors in each
> > row. Those rows are in a panable area so it's easy to scroll them. Those
> > colors are taken from a palette and (maybe) colors that hav
2009/9/26 Cornelius Hald :
> So how about a dialog that just shows n rows with 3 to 4 colors in each
> row. Those rows are in a panable area so it's easy to scroll them. Those
> colors are taken from a palette and (maybe) colors that have been
> selected in the advanced dialog are appended at the t
On Fri, 2009-09-25 at 22:55 +0200, Thomas Perl wrote:
> Depending on the use case, having a nice finger-friendly color palette
> could be *much* better than letting the user fine-tune the colors. I think
> most color-choosing tasks (e.g. in Conboy) are not about getting some
> really specific shade
2009/9/25 gary liquid :
> incidentally, there is a colorwheel in standard GTK
>
> http://commons.wikimedia.org/wiki/File:GTK_color_chooser.png
>
> whilst the number boxes themselves are not finger friendly (they could be
> replaced with popouts of some kind)
> the dialog itself certainly fits withi
there is an lot of very good dialog here :)
On Fri, Sep 25, 2009 at 9:14 AM, Murray Cumming wrote:
> On Thu, 2009-09-24 at 08:28 +0200, Cornelius Hald wrote:
> > Hi!
> >
> > There are some important widgets which are deprecated without a
> > replacement in Fremantle. Those widgets are still ava
Hi,
yes, the colorwheel would have to be finger-friendly. This is quite
difficult with a wheel.
I have thought a bit about it and found another hopefully
user-friendly alternative.
I think that HSV sliders are more comprehensible than RGB for normal people.
The H slider could show the color range
On Thu, 2009-09-24 at 08:28 +0200, Cornelius Hald wrote:
> Hi!
>
> There are some important widgets which are deprecated without a
> replacement in Fremantle. Those widgets are still available, but they
> are not fully finger-friendly or don't look good.
When this is just about regular GTK+ widge
From: Cornelius Hald
> > In hildon was not required to created a specific dialog for the
> > HildonDateButton or the HildonTimeButton. Both uses the current
> > HildonPickerDialog. Why do you think that a specific dialog is
> > required? What features do you think that misses HildonPickerDialog?
Hi!
On Fri, 2009-09-25 at 00:16 +0300, Claudio Saavedra wrote:
> Until you give it a try, it's only speculations. That's why I suggest
> that we work together on moving things forward.
I totally agree that we should work together! Lets just give it a quick
try to see whether or not we're talking
ext Claudio Saavedra wrote:
> Well, I would personally prefer to see more people involved in hildon
> instead of working on their own, specially now that there's clearly a
> gap to be filled between the toolkit set that Diablo (or even plain GTK
> +) has and what's part of Maemo 5 one. The only r
o.org] On Behalf Of ext
>Martin Grimme
>Sent: 24 September, 2009 23:58
>To: Cornelius Hald
>Cc: maemo-dev
>Subject: Re: Community widgets for Fremantle
>
>The color chooser dialog is nice for people who know RGB. But
>regular users don't know RGB so it won't be
El jue, 24-09-2009 a las 20:56 +0200, Cornelius Hald escribió:
> Hello again and sorry for the delay!
>
> I'll try to answer the mails from Claudio and API here. Just too many
> mails to reply one by one, so I'm replying to myself :P
>
> First, my proposal was not meant as a affront towards Igali
The color chooser dialog is nice for people who know RGB. But regular
users don't know RGB so it won't be of much use, actually. A color
wheel would be more understandable.
Martin
2009/9/24, Cornelius Hald :
> This would be my first contribution to the Hildon community widgets:
>
> http://zwong
On Thu, 2009-09-24 at 16:13 +0200, Piñeiro wrote:
> > Personally I would like to see the following widgets:
> >
> > * HildonExtrasColorButton:
> > A button that looks like a HildonCheckButton, but instead of the check
> > mark it displays the selected color. When clicking this button a
> > Hildon
Hi Andrew,
> I have started work on a pannable-font-selector and
> pannable-color-selector (for lack of better names at this point) with
> the help and input of some of the folks at #maemo. I want to have a
> dialog and button for each of them as well as you suggest, to make it
> as easy as possi
This would be my first contribution to the Hildon community widgets:
http://zwong.de/wp-content/uploads/2009/09/check_button.png
At the moment it's called ConboyCheckButton, but I will change the name
once we come up with something.
It has the same features like a HildonButton (2 labels with diff
Hello again and sorry for the delay!
I'll try to answer the mails from Claudio and API here. Just too many
mails to reply one by one, so I'm replying to myself :P
First, my proposal was not meant as a affront towards Igalia or the
Hildon team. You have been very helpful in the past and I'm really
I think it would be best if these widgets made it into hildon - people
would get the most use out of them. When I get my versions into a more
usable state, I will submit them to the hildon team. It should at least
be a good starting point.
I am modelling my widgets after current and past hild
From: Claudio Saavedra
> El jue, 24-09-2009 a las 08:28 +0200, Cornelius Hald escribió:
> >
> > I propose to create a garage project, let's say 'hildon-extras' with
> > the goal of creating a library containing missing widgets where more
> > than one person is interested in.
>
> I am not sure w
From: Andrew Olmsted
> I have started work on a pannable-font-selector and pannable-color-selector
> (for lack of better names at this point) with the help and input of some of
> the folks at #maemo. I want to have a dialog and button for each of them as
> well as you suggest, to make it as easy
From: Cornelius Hald
> There are some important widgets which are deprecated without a
> replacement in Fremantle. Those widgets are still available, but they
> are not fully finger-friendly or don't look good.
As far as I remember, we have a conversation with you about the color
selector and pi
El jue, 24-09-2009 a las 08:28 +0200, Cornelius Hald escribió:
>
> I propose to create a garage project, let's say 'hildon-extras' with
> the goal of creating a library containing missing widgets where more
> than one person is interested in.
I am not sure why you need a new library. We've propos
Hi,
I have started work on a pannable-font-selector and pannable-color-selector
(for lack of better names at this point) with the help and input of some of
the folks at #maemo. I want to have a dialog and button for each of them as
well as you suggest, to make it as easy as possible for the user.
Hi!
There are some important widgets which are deprecated without a
replacement in Fremantle. Those widgets are still available, but they
are not fully finger-friendly or don't look good.
Developers are expected to implement those widgets by them selfs which
could lead us to a situation where we
89 matches
Mail list logo
