subject:"Community widgets for Fremantle"

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 days back and forth with no real progress
 in terms of UI mock-ups and code :/

Yes, there was enough talk and not much action. Let's changed that!

 Here's my proposed 10-step-guide to achieving our goal:
 
   1. Pick a name (hildon-extras or hexy; suggested by Cornelius)
   2. Register a project at garage.maemo.org
   3. Set up the initial project structure

I'll do that. I would say we use hildon-extras as the garage project
name and use the He prefix in our code. So, for example,
HeColorChooser, HE_IS_COLOR_CHOOSER, HE_TYPE_COLOR_CHOOSER, etc...
It's short and Andrew is already using it.

I let you all know once it's set up. And everyone how wants to
contribute can join of course.

Objections?

Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Color wheel mockup (was: Community widgets for Fremantle)

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 right, the use can adjust the selected color in greater
 detail, even entering the HTML-equivalent code.
 
 I thought about adding a way to select the kind of values to be entered
 (RGB, CMYK, HSL...).
 
 What do you think?

thanks for joining the discussion and for providing the mockup :)

First, I like that you've not given up on the color wheel. I think it's
a nice way of selecting a color. The problems is, that it takes quite
some space, so the idea to use the complete window makes a sense here.

The problem is, that it seems a bit inconsistent with the rest because
most of the time simple dialogs are used. For me personally this is not
a big problem, but it might be for others.

I think the buttons on the left would not be needed as this dialog would
already be the Advanced view of the simple color chooser. If you
remove those and save some space on the right, maybe you could fit it
into a normal dialog?

It will probably get a bit difficult to find the right Advanced
dialog. But it's great that we already have choice :)

What do other think about this mockup?
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 not :)

To give other people an easy way to look at it, I created some
screenshots here:

http://zwong.de/wp-content/uploads/2009/10/screenshot11.png
http://zwong.de/wp-content/uploads/2009/10/screenshot09.png
http://zwong.de/wp-content/uploads/2009/10/screenshot12.png

I have made the font selection and colour selection widgets as
self-contained as possible - they are not integrated in any way in the
countdown-home code. In my case, I decided to try to parallel past
hildon colour and font dialogs as much as possible.

To this end I now have six different widgets, each prefaced with he
for hildon-extras (but much shorter). They are:

he-color-button, he-color-dialog, he-color-selector
he-font-button, he-font-dialog, he-font-selector

As for developing with these widgets, the developer need only put a
font/color button in his/her application and he/she can set and retrieve
the font/colour through that. For example, the he-color-button
automatically creates a he-color-dialog for user input containing an
he-color-selector. The developer can use the dialog and selector
widgets as well, but it is just easier to put a button in and have
everything controlled.

I think that's the way to go.

I would welcome any thoughts on my particular implementation. The
source can be obtained at:
http://repository.maemo.org/extras-testing/pool/fremantle/free/source/c/countdown-home/countdown-home_0.5-8.tar.gz

The implementation looks fine to me. I'm not an expert, though :)

As for the look and feel I have the following ideas (I think I already
wrote them somewhere, but cannot remember):

- Render the font names in the font that they represent. You could then
get rid of the preview label at the top.

- On the font button a bit more spacing between the size and the
separator would be good. Or use picker button style (see below).

- I think it would be good to get the labels, which you now have in
front of the color button and the font button, into the button itself.
That's how Hildon is doing it mostly. Therefore:

-- Put the label of the color button onto the button itself to make it
look a bit like a check button. The color field on the button must then
shrink of course, but I think it's not needed to be so big anyways.

-- Put the label of the font button onto the button itself. I think you
could use the feature of the HildonButton here which allows two labels.
The first label would be the label/caption of the button (e.g. Title
font) and the second label could show Courier New (18).

- The color selector works, but I think it would be more powerful if it
would be combined with the simple color picker that Thomas proposed.
Also the selected color is quite big, maybe this space could be used
otherwise. Please also have a look at the mockup posted by Felipe. Maybe
you could work somehow together.

Sorry for my late answer and thanks for the work!
Conny

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-10-01 Thread Andrew Olmsted

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, but didn't have time to do before the release. It is
made a bit difficult by the fact that inheriting HildonButton only gives
you access to the _text_ that you put in the value field, whereas for
both buttons I am packing something other than simple text in there. I
think the alternate solution would be to duplicate the functionality of
the HildonButton within HeColorButton and HeFontButton - or better yet
within an abstract class HeButton that provides the control
HeColorButton and HeFontButton need without the need to duplicate.

Having a simple and advanced colour selector is a good idea, and a
simple picker like those that have been posted here could definitely be
implemented along side the less-beginner-friendly but more-fine-tunable
version I started with.

Your other suggestions for the look and feel of the widgets should be no
problem.

Thanks,
Andrew

Cornelius Hald wrote:
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 not :)

To give other people an easy way to look at it, I created some
screenshots here:

http://zwong.de/wp-content/uploads/2009/10/screenshot11.png
http://zwong.de/wp-content/uploads/2009/10/screenshot09.png
http://zwong.de/wp-content/uploads/2009/10/screenshot12.png

To this end I now have six different widgets, each prefaced with he
for hildon-extras (but much shorter). They are:

he-color-button, he-color-dialog, he-color-selector
he-font-button, he-font-dialog, he-font-selector

I think that's the way to go.

The implementation looks fine to me. I'm not an expert, though :)

As for the look and feel I have the following ideas (I think I already
wrote them somewhere, but cannot remember):

- Render the font names in the font that they represent. You could then
get rid of the preview label at the top.

- On the font button a bit more spacing between the size and the
separator would be good. Or use picker button style (see below).

- I think it would be good to get the labels, which you now have in
front of the color button and the font button, into the button itself.
That's how Hildon is doing it mostly. Therefore:

Sorry for my late answer and thanks for the work!
Conny

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 
 implementable.  Getting the label onto the button is something I 
 definitely want, but didn't have time to do before the release.  It is 
 made a bit difficult by the fact that inheriting HildonButton only gives 
 you access to the _text_ that you put in the value field, whereas for 
 both buttons I am packing something other than simple text in there.  I 
 think the alternate solution would be to duplicate the functionality of 
 the HildonButton within HeColorButton and HeFontButton - or better yet 
 within an abstract class HeButton that provides the control 
 HeColorButton and HeFontButton need without the need to duplicate.

I know both problems too :) Time is always short and there are those
problems with the inheritance tree. I have a HeCheckButton (check button
with two labels) which is a complete reimplementation of HildonButton
and I'm not happy about it, but it was the only possible solution that I
found.

As you said, once we have a place to share the code we can hopefully put
much of this into a common HeButton. I applied for a garage project
about an hour ago, so things should start moving the next days.

 Having a simple and advanced colour selector is a good idea, and a 
 simple picker like those that have been posted here could definitely be 
 implemented along side the less-beginner-friendly but more-fine-tunable 
 version I started with.
 
 Your other suggestions for the look and feel of the widgets should be no 
 problem.

I'm happy that we agree on those things and I'm looking forward to when
things are coming together. As soon as the project is set up, we can
start putting the pieces together :)

Thanks!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Kimmo Hämäläinen

On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
wrote:
 Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com
 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.

I don't understand, wouldn't the forked/new widget library also have
this same problem?

 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 outside.

You could put this unstable version to some non-Nokia repository and
distribute it easily enough. It's understandable that the Nokia repo
would not have it before a stabilisation period because it could break
existing software.

 At least not without making it terrible obvious that it is not just a
 mistake.  If 'everybody' agrees that, yes, let's release updates to
 libhildon1 from Maemo Extras, then it can be done.
 
 But right now, I would say that this is far from business as usual.
 That's why I am emphasizing this.  Would be cool if it becomes business
 as usual, of course.

-Kimmo


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Niels Breet

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 outside.

 You could put this unstable version to some non-Nokia repository and
 distribute it easily enough. It's understandable that the Nokia repo
 would not have it before a stabilisation period because it could break
 existing software.


I think Marius is trying to say that external repositories aren't allowed
to update system libraries as this breaks SSU.


 -Kimmo

- Niels

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Andrew Flegg

On Wed, Sep 30, 2009 at 05:25,  quim@nokia.com 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]
 - It is clear that Hildon must go upstream around GNOME and GTK+ [...]
 - The Maemo team has learned a thing or to, thanks to many factors [...]

Good reasons. I hope we can test them at some point.

 I hope you can keep all Hildon contributions around the Hildon trunk
 repository and within one real project. Hildon needs all the community
 interest and support concentrated in one point. Spreading energies can be
 too expensive. Like Claudio says, if the problem is the distribution then
 let's concentrate on the root of the real problem while developing code
 and features in the optimal way.

Agreed. I'm not sure distribution is the *whole* problem though. Let's
assume Nokia are willing to ship an updated libhildon, Maemo Updates
are scheduled and planned - they're not going to be as frequently as
an additional library (libhildon-extras, say) can be shipped. This
exposes the following problems:

  * Community testing of the new widgets becomes harder.

  * Shipping a new app which has been the spur for developing a new
widget becomes blocked on to a future SSI.

  * Reuse of a new widget developed for app A in an existing app, B,
also becomes slower.

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 libhildon *and
then waiting for Nokia to ship that update* (assuming that it is
shipped at all) will be very effective at all. Unless I'm missing
something and Nokia aren't just willing to ship a libhildon update,
but you're willing to ship one when we (i.e. the widget developers
and libhildon maintainers) ask.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Niels Breet

On Wed, September 30, 2009 10:47, Andrew Flegg wrote:
 On Wed, Sep 30, 2009 at 05:25,  quim@nokia.com 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 libhildon *and then
 waiting for Nokia to ship that update* (assuming that it is shipped at
 all) will be very effective at all. Unless I'm missing something and Nokia
 aren't just willing to ship a libhildon update, but you're willing to ship
 one when we (i.e. the widget developers and libhildon maintainers) ask.


Unless the SSU is being done at regular intervals, because then you can at
least aim for a certain date. But even then, you would need to know if
your updated lib will be part of the SSU in the first place.

 Cheers,


 Andrew

- Niels


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread quim.gil

 On Wed, September 30, 2009 10:47, Andrew Flegg wrote:
  On Wed, Sep 30, 2009 at 05:25,  quim@nokia.com 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 libhildon *and then
  waiting for Nokia to ship that update* (assuming that it is shipped at
  all) will be very effective at all. Unless I'm missing something and Nokia
  aren't just willing to ship a libhildon update, but you're willing to ship
  one when we (i.e. the widget developers and libhildon maintainers) ask.
 

 Unless the SSU is being done at regular intervals, because then you can at
 least aim for a certain date. But even then, you would need to know if
 your updated lib will be part of the SSU in the first place.

Projects like GNOME or Ubuntu need 6 month iterations between stable releases. 
Would you say that 6 months after the Maemo 5 final is good enough or too slow?

Quim

PS: if 6 months to reach end users is considered too slow for an official 
widget that today is still under discussion then perhaps we need to re-check 
expectations based on real life examples? 

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Marius Vollmer

ext Alberto Garcia agar...@igalia.com 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 some practical problems about that.

 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.

 What else?

You have to be careful to never link two libraries with overlapping
symbols into the same process.  In the case of libhildon, that is
probably manageable, and the possibility can probably be ignored.

If necessary, there can even be a second maemo-launcher.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Marius Vollmer

Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com
writes:

 On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
 wrote:
 Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com
 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.

 I don't understand, wouldn't the forked/new widget library also have
 this same problem?

No, since it would have a different name.

Anyway, I realize I have been too negative about all this.  With some
care, 'forking' libhildon and distributing it via Maemo Extras should be
perfectly doable.

'Forking' means using a different package name for everything (source,
binary, -dev, etc), and I put it in quotes since it would be done by the
original libhildon maintainers.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Claudio Saavedra

El mié, 30-09-2009 a las 14:10 +0300, Marius Vollmer escribió:
 ext Alberto Garcia agar...@igalia.com 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 some practical problems about that.
 
  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.
 
  What else?
 
 You have to be careful to never link two libraries with overlapping
 symbols into the same process.  In the case of libhildon, that is
 probably manageable, and the possibility can probably be ignored.

This shouldn't be a problem. Other distros with more real world
experience than maemo cope with this pretty well. For instance, Debian
unstable has nowadays two parallel installable versions of libsoup.
Objects link against either of them depending on their needs. There
should never be the case when someone is linking against the two. Not
even if dinamically loadable modules are in place.

In our case, Nokia applications and libraries link against what's now
shipped by Nokia. That's not going to change. If there is a parallel
installable version of hildon, those interested on using it link against
it and so should all the modules that they want to load in runtime or
whatever.

And as far as I know, maemo-launcher only boosts the GTK+ library, but I
might be wrong.

Claudio


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-30 Thread Thomas Perl

2009/9/30 Marius Vollmer marius.voll...@nokia.com:
 Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com
 writes:

 On Tue, 2009-09-29 at 16:44 +0200, Vollmer Marius (Nokia-D/Helsinki)
 wrote:
 Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com
 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.

 I don't understand, wouldn't the forked/new widget library also have
 this same problem?

 No, since it would have a different name.

 Anyway, I realize I have been too negative about all this.  With some
 care, 'forking' libhildon and distributing it via Maemo Extras should be
 perfectly doable.

 'Forking' means using a different package name for everything (source,
 binary, -dev, etc), and I put it in quotes since it would be done by the
 original libhildon maintainers.

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.

This thread has gone for two days back and forth with no real progress
in terms of UI mock-ups and code :/

Here's my proposed 10-step-guide to achieving our goal:

  1. Pick a name (hildon-extras or hexy; suggested by Cornelius)
  2. Register a project at garage.maemo.org
  3. Set up the initial project structure
  4. Implement the color chooser as discussed
  5. Publish the library to Extras-Devel
  6. Use the library in GPE, Conboy, etc..
  7. Publish new versions of GPE, Conboy, etc.. to Extras-Devel
  8. Do the promotion / testing stuff until everything is in Extras
  9. Be happy to have a shared library in Extras :)
 10. There is no step 10

I'll be happy to jump in at step 4 :p

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 existance before even thinking of doing that.

Claudio

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Graham Cobb

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 you haven't, I'd suggest you to go google
 for discussions on its existance before even thinking of doing that.

It isn't a great solution, I agree, but it is a matter of scale and timing.  
The way I had intended was, I think, rather different from libegg in that I 
had imagined that probably only one or two projects would use the standalone 
code before the decision was made to incorporate it into Hildon or into 
another (community) library.  But, you re right, that it could very rapidly 
degenerate if the guesses for scale and timing are wrong!

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 in 
one place.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Cornelius Hald

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 you haven't, I'd suggest you to go google
 for discussions on its existance before even thinking of doing that.

It certainly has its drawbacks. But then again, what's your suggestion?

Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 in one place.

If you happen to have symbols with the same in hildon and the eventual
library you want to create, you will have symbol clashing.

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 to the hildon variants. And I can tell you that you risk
having a lot of developers simply not porting to the Hildon variants
because the community versions are good enough for them.

Long term maintenance of a library is complex, and you'll have a lot of
hassle in the future going that way. On the other hand, there's Nokia
and their intentions to work together with the community in Hildon.
You'll have to make a choose between control and maintainability. Of
course, the implications of Nokia intentions would be good to know
beforehand.

Claudio


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 them and still carry them around for people without
  time to migrate to the hildon variants. And I can tell you that you risk
  having a lot of developers simply not porting to the Hildon variants
  because the community versions are good enough for them.
 
 Absolutely.  That was one reason I wanted to make it a little bit harder for 
 people to use the community versions, so only the people who really needed 
 them would use them before they went into Hildon.  But, as you have pointed 
 out, that way lies madness.
 
 So, I think we just have to face this.
 
  Long term maintenance of a library is complex, and you'll have a lot of
  hassle in the future going that way. On the other hand, there's Nokia
  and their intentions to work together with the community in Hildon.
  You'll have to make a choose between control and maintainability. Of
  course, the implications of Nokia intentions would be good to know
  beforehand.
 
 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 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.

   So, we have to have some 
 library (or else everyone who wants to run on Fremantle has to code the 
 widgets themselves).  Also, as we want these to be available very quickly, it 
 is possible there will be some changes before they are accepted into Hildon 
 (the Nokia people are presumably very busy with last minute activities before 
 the launch and are not going to be reviewing and approving specs).  
 
 So, in my view, we have no option but to have a community library.  We should 
 push to move things as quickly as possible into Hildon (with as few changes 
 as possible except in naming) and deprecate them in the community library (at 
 which time I would expect the community to lose interest in maintaing them).  
 You are certainly right that there will be many applications still using the 
 deprecated versions for a long time to come.  But that is no worse (in fact a 
 lot better) than many applications hacking together their own widgets so they 
 all have different bugs (and different UIs).

I have to be honest and say that I don't like this whole discussion too
much. We are talking all the time about hypotetical things that need to
be done, and what will be done when these hypotetical things get
hypotetically merged, and so on. Too much hypothesis, too little facts.

If I was in your place, I'd start by going the right way and assuming
that everyone has the best intentions for hildon: just clone the hildon
tree, put the widgets in place, work on your clone, get something that
can be shown, file a bug. If for whatever reason these don't get merged
or you see things going too slowly or too much bureaucracy, nothing is
stopping you from diverting then.

I don't see the need to divert before even attempting to join the
project.

Claudio


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Andrew Flegg

On Tue, Sep 29, 2009 at 13:11, Claudio Saavedra csaave...@igalia.com 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 possibly close to
zero.

I don't think it's worth the effort maintaining a Hildon fork for a
Harmattan release of Hildon, when we don't know what other changes
will need making to Hildon to make it compatible with Harmattan's UI.

A separate library at this point sounds the most sensible, possibly
using the same names and stuff for easier inclusion at a later date.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Cornelius Hald

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 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.

I don't think that either, but a first version with 2-4 widgets could be
ready within a month or two. Of course depending of participation :)

 I have to be honest and say that I don't like this whole discussion too
 much. We are talking all the time about hypotetical things that need to
 be done, and what will be done when these hypotetical things get
 hypotetically merged, and so on. Too much hypothesis, too little facts.

I know you want the code in Hildon. And we all know that this would be
nice. So basically we all want this. But as long as we don't know that
there will be another Hildon release and when this Hildon release will
be, I see now point in even trying to commit to Hildon. Yes, the code
should be there, but of what use is this code if it's never shipped?

Also you didn't reply to my questions regarding my check button
implementation yet. It would be interesting (at least for me) to get a
feeling what kind of contribution would be accepted.

 If I was in your place, I'd start by going the right way and assuming
 that everyone has the best intentions for hildon: just clone the hildon
 tree, put the widgets in place, work on your clone, get something that
 can be shown, file a bug. If for whatever reason these don't get merged
 or you see things going too slowly or too much bureaucracy, nothing is
 stopping you from diverting then.

Our time is also limited, so I really don't want to waste it on my
personal hildon tree if it's not even clear what will eventually be
accepted and when this will be shipped. I'm not talking about a detailed
schedule here, but a rough number. How many updates have there been for
Gtk and Hildon for Diablo?

Also it's a completely different thing if I'm developing a widget under
the assumption that I can make changes to the complete Hildon tree. Or
if I develop under the assumption that Hildon is as it is and I have to
work with that.

So if I'm developing under the assumption that I can change Hildon, I
cannot use this code anymore once it is decided that there will be no
further Hildon updates.


Anyways, it's not even clear, that we will come up with a lot of code.
It's not clear that people will use our code. So why not just start
coding now in a garage project and later if we really have something see
whether or not we can get it into hildon? As a start I really would like
to have a low entry barrier.

I think we cannot just ignore that the Hildon project plays a special
roll in the Nxxx universe. Maybe it's freed from it's chains one day -
then we can take action. The sooner the better of course.

Cheers!
Conny



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Marius Vollmer

ext Claudio Saavedra csaave...@igalia.com 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 updates to
libhildon that applications could rely on for, I dunno, 6 months or so.

 If I was in your place, I'd start by going the right way and assuming
 that everyone has the best intentions for hildon: just clone the hildon
 tree, put the widgets in place, work on your clone, get something that
 can be shown, file a bug. If for whatever reason these don't get merged
 or you see things going too slowly or too much bureaucracy, nothing is
 stopping you from diverting then.

This point is now.  I can tell you already now that things will be too
slow.  There is no point in finding this out the hard way.

 I don't see the need to divert before even attempting to join the
 project.

We need to find a setup where the community can contribute to libhildon,
and at the same not being able to release libhildon.

/me goes off to get some coffee and think while staring at the snow
covered Helsinki landscape...

Ok, can't be done in any sane way.  So my best proposal now is to create
a separate library for the community widgets, without any hope of ever
moving the widgets into libhildon.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Graham Cobb

On Tuesday 29 September 2009 13:49:10 Marius Vollmer wrote:
 ext Claudio Saavedra csaave...@igalia.com 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 updates to
 libhildon that applications could rely on for, I dunno, 6 months or so.

Exactly.   Hildon releases will not under the control of even the Hildon team 
(let alone the community): they will be tied to Nokia platform releases and 
Nokia QA schedules.   Due to the signing stuff the community cannot replace 
Hildon even if we wanted to.

 Ok, can't be done in any sane way.  So my best proposal now is to create
 a separate library for the community widgets, without any hope of ever
 moving the widgets into libhildon.

I am missing something.  Why do you (and Claudio) believe that if we start off 
by implementing the widgets in a community library it will be hard to later 
move them into Hildon?  I realise why it will be hard to get people to stop 
using the community versions but is there some reason it will be hard to add 
the community-developed widgets to Hildon?

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 library name but 
containing the whole hildon library) on our own schedule.  Any apps which 
wanted to use the new features would have to link against the community 
library names instead of the standard library names but the Nokia apps would 
be unchanged.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Marius Vollmer

ext Graham Cobb g+...@cobb.uk.net 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 and will remove libhildon1 to
make room for it.  (Haven' really tested this yet.)

This is not a nice thing to do, of course, and should be avoided.

 Ok, can't be done in any sane way.  So my best proposal now is to create
 a separate library for the community widgets, without any hope of ever
 moving the widgets into libhildon.

 I am missing something.  Why do you (and Claudio) believe that if we start 
 off 
 by implementing the widgets in a community library it will be hard to later 
 move them into Hildon?  I realise why it will be hard to get people to stop 
 using the community versions but is there some reason it will be hard to add 
 the community-developed widgets to Hildon?

No, you are right, it should not be hard to accept contributions to
libhildon.

I was probably exaggerating too much: If by moving we mean to just
copy the source code from one library into another, then the friction
caused by this is probably too high to be worth the trouble.  If by
move we mean to offer the same kind of widget in two libraries, with
different names and in a non-conflicting way, then moving the
community widgets into libhildon is realistic and should be part of the
plan from the beginning.

 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 library name but 
 containing the whole hildon library) on our own schedule.  Any apps which 
 wanted to use the new features would have to link against the community 
 library names instead of the standard library names but the Nokia apps would 
 be unchanged.

This is tricky, of course, since the two libraries will contain
overlapping symbols.  They must never ever be linked into the same
process, which will probably be a source of all kinds of stupid and
unnecessary hair pulling and teeth gnashing.  Just think of plugins and
libraries using libraries.


Whatever we do, will be a testimony to how Nokia is not part of the
community, and how Maemo isn't really Open Source enough.  So, having
all these practical problems in view here, how would the ideal world
look like that wouldn't have these problems?

Nokia would have to be able to release new versions of platform
components very quickly, at a speed that matters for application
development.  These platform packages should follow the Maemo Extras
promotion process.

Also, Nokia would probably have to allow partial OS updates: if a
application needs a new libhildon, then it should be possible to install
only that new libhildon and not a whole new OS version.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread gary liquid

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 with good stuff and worrying about the
specific implementation.

fiferboy, conny, thomas - excellent bits of code and usable dialogs seem to
be appearing!

fifer, conny - please try to ensure your dialogs are as self contained as
possible and documented to some degree so if someone wants to lift them from
your projects its as easy as possible.

should we put up a wiki page with links to the in use projects along with
screenshots and howto include in your project and stuff - leaving the code
basically where they are now and try to work on getting decent
implementations together?

that seems like minimal fuss next step until we can haggle a library or
project etc

we are mostly developers and like to show off screenies
not worry about these niggly bits - if someone with determination to build
it as a library comes along and pulls those examples in - great

gary




On Tue, Sep 29, 2009 at 1:23 PM, Graham Cobb
g+...@cobb.uk.netg%2b...@cobb.uk.net
 wrote:

 On Tuesday 29 September 2009 13:49:10 Marius Vollmer wrote:
  ext Claudio Saavedra csaave...@igalia.com 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 updates to
  libhildon that applications could rely on for, I dunno, 6 months or so.

 Exactly.   Hildon releases will not under the control of even the Hildon
 team
 (let alone the community): they will be tied to Nokia platform releases and
 Nokia QA schedules.   Due to the signing stuff the community cannot replace
 Hildon even if we wanted to.

  Ok, can't be done in any sane way.  So my best proposal now is to create
  a separate library for the community widgets, without any hope of ever
  moving the widgets into libhildon.

 I am missing something.  Why do you (and Claudio) believe that if we start
 off
 by implementing the widgets in a community library it will be hard to later
 move them into Hildon?  I realise why it will be hard to get people to stop
 using the community versions but is there some reason it will be hard to
 add
 the community-developed widgets to Hildon?

 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 library name but
 containing the whole hildon library) on our own schedule.  Any apps which
 wanted to use the new features would have to link against the community
 library names instead of the standard library names but the Nokia apps
 would
 be unchanged.

 Graham
 ___
 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: Community widgets for Fremantle

2009-09-29 Thread Kimmo Hämäläinen

On Tue, 2009-09-29 at 14:49 +0200, Vollmer Marius (Nokia-D/Helsinki)
wrote:
 ext Claudio Saavedra csaave...@igalia.com 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 updates to
 libhildon that applications could rely on for, I dunno, 6 months or so.

What prevents the community from releasing this unstable libhildon
before Nokia does the stable release?  That way both the community and
Nokia could use the same code tree.  Commits would be reviewed by other
libhildon developers, of course.

-Kimmo


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Andrew Olmsted

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.

To this end I now have six different widgets, each prefaced with he
for hildon-extras (but much shorter). They are:

he-color-button, he-color-dialog, he-color-selector
he-font-button, he-font-dialog, he-font-selector

Thanks,
Andrew (fiferboy)

gary liquid wrote:

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 with good stuff and worrying
about the specific implementation.

fiferboy, conny, thomas - excellent bits of code and usable dialogs
seem to be appearing!

fifer, conny - please try to ensure your dialogs are as self contained
as possible and documented to some degree so if someone wants to lift
them from your projects its as easy as possible.

should we put up a wiki page with links to the in use projects along
with screenshots and howto include in your project and stuff - leaving
the code basically where they are now and try to work on getting
decent implementations together?

that seems like minimal fuss next step until we can haggle a library
or project etc

we are mostly developers and like to show off screenies
not worry about these niggly bits - if someone with determination to
build it as a library comes along and pulls those examples in - great

gary

On Tue, Sep 29, 2009 at 1:23 PM, Graham Cobb g+...@cobb.uk.net
mailto:g%2b...@cobb.uk.net wrote:

On Tuesday 29 September 2009 13:49:10 Marius Vollmer wrote:
ext Claudio Saavedra csaave...@igalia.com
mailto:csaave...@igalia.com 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 updates to
libhildon that applications could rely on for, I dunno, 6 months
or so.

Exactly. Hildon releases will not under the control of even the
Hildon team
(let alone the community): they will be tied to Nokia platform
releases and
Nokia QA schedules. Due to the signing stuff the community
cannot replace
Hildon even if we wanted to.

Ok, can't be done in any sane way. So my best proposal now is
to create
a separate library for the community widgets, without any hope
of ever
moving the widgets into libhildon.

I am missing something. Why do you (and Claudio) believe that if
we start off
by implementing the widgets in a community library it will be hard
to later
move them into Hildon? I realise why it will be hard to get
people to stop
using the community versions but is there some reason it will be
hard to add
the community-developed widgets to Hildon?

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 library name but
containing the whole hildon library) on our own schedule. Any
apps which
wanted to use the new features would have to link against the
community
library names instead of the standard library names but the Nokia
apps would
be unchanged.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org mailto:maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

___

Re: Community widgets for Fremantle

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 library name
 but 
  containing the whole hildon library) on our own schedule.  Any apps
 which 
  wanted to use the new features would have to link against the
 community 
  library names instead of the standard library names but the Nokia
 apps would 
  be unchanged.
 
 This is tricky, of course, since the two libraries will contain
 overlapping symbols.  They must never ever be linked into the same
 process, which will probably be a source of all kinds of stupid and
 unnecessary hair pulling and teeth gnashing.  Just think of plugins
 and
 libraries using libraries.

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.

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 link against in
their applications.

If Nokia wants to stick to use a frozen library version for their
product, that's their business. Community can still move forward.

Claudio


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread quim.gil

 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 regressions... Why not? 
The Fremantle program runs their tests on the software pre-installed. If new 
widgets are introduced but they are not used by the official apps the probkem 
is perhaps not that big. Again, if good design, programming and testing back 
those new widgets.

This is no different than any mature piece of software being deployed in 
commercial devices. You can try out these widgets in an unstable branch, Nokia 
can keep the stable branch for Maemo. If patches in unstable are proven to work 
then libhildon can have this minor update.

In the meantime you can work on more radical changes if you wish, that will 
belong to a future major update perhaps. At some point Harmattan will be under 
our feet, Hildon will be out of Nokia's domain and whoever in the community 
works in the Harmattan version will be able to decide what comes in and what 
stays out.

Quim Gil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Marius Vollmer

Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com
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 division between packages that are
released by Nokia, and the rest.  You can not update a Nokia package
from the outside.

At least not without making it terrible obvious that it is not just a
mistake.  If 'everybody' agrees that, yes, let's release updates to
libhildon1 from Maemo Extras, then it can be done.

But right now, I would say that this is far from business as usual.
That's why I am emphasizing this.  Would be cool if it becomes business
as usual, of course.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Andrew Flegg

On Tue, Sep 29, 2009 at 15:18,  quim@nokia.com 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 the community and don't introduce risks or
 regressions... Why not?

Because there's a perceived *risk* of risks  regressions. How many of
our App Manager patches shipped to Diablo users once Maemo Devices had
moved on to Fremantle? None.

Is there any reason to suspect that the situation will be different
with Fremantle once Maemo Devices is pushing for Harmattan?

Community-maintained widgets need to be releasable and testable by the
community without Nokia involvement. Nokia are just too slow (and this
isn't *necessarily* a Bad Thing).

When the Hildon community takes ownership and responsibility for
shipping a Harmattanised Hildon, additional widgets can (and *should*)
be merged then. Hell, they can be merged before then, but whilst Nokia
controls the distribution of libhildon on Maemo, these extra widgets
should be in libhildon-extra (or whatever).

Cheers,

Andrew

PS. Posting rate not diminished now I'm not on the council ;-)

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Javier Jardón

2009/9/29 Claudio Saavedra csaave...@igalia.com:
 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 link against in
 their applications.

To achieve this, I think that would be great that we can compile
Hildon outside maemo SDK.
There already is a bug about this here: [1]

This will make more easy new contributions because It's not necessary
to install all the maemo SDK.

Indeed, I've been able to compile a hildon2 program in a normal linux
machine with a patched version of hildon2.

Also, libhildon is now in a gitorious repo [2] (seems to be
provisional, see [3] for more info), so I think that clone the hildon
repo and start the contributions is more easy than set up a new maemo
garage project ;)

Best Regards

[1] https://bugs.maemo.org/show_bug.cgi?id=4605
[2] http://gitorious.org/hildon
[3] https://garage.maemo.org/pipermail/hildon-devel/2009-September/08.html

-- 
Javier Jardón Cabezas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Alberto Garcia

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, that the community can maintain in extras and
  link against in their applications.
 
 To achieve this, I think that would be great that we can compile
 Hildon outside maemo SDK.

Of course that would be a nice thing, but it doesn't have much to do
with the problem we're discussing here.

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Alberto Garcia

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 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.

What else?

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Felipe Erias Morandeira

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 adjust the selected color in greater
detail, even entering the HTML-equivalent code.

I thought about adding a way to select the kind of values to be entered
(RGB, CMYK, HSL...).

What do you think?


Regards,

Felipe


Cornelius Hald 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
 HildonExtrasColorChooserDialog is opened.

 * HildonExtrasColorChooserDialog:
 A dialog that displays a HildonExtrasColorChooser.

 * HildonExtrasColorChooser:
 A widget that lets the user select a color by only using fingers. I'm
 not yet sure how it should look like, but personally I would like
 something with three color wheels or touch selectors for red, green and
 blue. Then next to it a field shows the composed color of those three
 'color wheels'. Plus an area where you have, for example, the last 8
 used colors.



colorwheel.svg.gz
Description: GNU Zip compressed data


signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 applications.
  
  Yes, but there are some practical problems about that.
 
 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 on the maemo-launcher issue?

Claudio


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread Alberto Garcia

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 on the maemo-launcher issue?

maemo-launcher preloads libhildon, doesn't it ?

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-29 Thread quim.gil

  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  regressions. How many of
 our App Manager patches shipped to Diablo users once Maemo Devices had
 moved on to Fremantle? None.

 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. Adding widgets doesn't affect the user experience, 
testing, etc of current widgets. If a new widget turns out to be conflictive it 
won't affect any official app since they will stick to the widgets used now for 
the Maemo 5 final release. Therefore the whole discussion of accepting 
enhancements is made more among platform developers without adding much of UI 
designers and product managers to the mix. If the changes don't bring any 
straings for localization all the better. This is very different compared to a 
pre-installed application.

- App Manager Diablo was moving to App Manager Fremantle both inside the Maemo 
team and there were clear project management instructions about where to put 
the resources. Instead, the Desktop team has mostly two different subteams for 
Hildon and the Qt based application framework for Harmattan since both projects 
require different timings and skills. The Hildon skills and mid term decisions 
are nowadays in practice more in the hands of GNOME developers working for 
Igalia, Lanedo, Openismus, Collabora... If they want to push Hildon forward and 
your patches and commitment are convincing you will need to deal with less and 
less Nokia internal project plans.


- It is clear that Hildon must go upstream around GNOME and GTK+ or will have 
clearly no sustainable future. The Maemo team needs to start handling this 
transfer of ownership. The schedule is not defined by the end of the Fremantle 
timeline but by the beginning of the Harmattan timeline. You have seen the 
Maemo Summit schedule and you know this time is coming already.

- The Maemo team has learned a thing or to, thanks to many factors including 
the App Manager Diablo contributions fiasco. We have contribution guidelines, 
we had Fremantle pre-releases since pre-alpha and you have here non-Nokians 
like Claudio or Berto able to discuss openly details about their are of 
responsibility and run entire garage projects and git repositories.

You will know better the technical decisions about packaging etc but at least 
you know my opinions as one of the persons in the Maemo team responsible of 
finding the best future for Hildon as a community supported project.

I hope you can keep all Hildon contributions around the Hildon trunk repository 
and within one real project. Hildon needs all the community interest and 
support concentrated in one point. Spreading energies can be too expensive. 
Like Claudio says, if the problem is the distribution then let's concentrate on 
the root of the real problem while developing code and features in the optimal 
way.

--
Quim Gil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-28 Thread Piñeiro

From: Thomas Perl th.p...@gmail.com

 2009/9/26 Cornelius Hald h...@icandy.de:
  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 top or bottom of
  that list. Maybe separated by some kind of separator.
  8 ---
  When clicking on of those color buttons a dialog like this opens:
  http://zwong.de/wp-content/uploads/2009/09/color_chooser_mock.png
  Probably the buttons/colors should be bigger or there should be 4 in a
  row. As I said, just a very quick mockup. Those buttons are pannable, so
  there are more colors available.
 
 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 very fine. Anyway, you can still use the three column color
selector and blabla, in order to allow the user to define a custom
extra color.

I suppose that you have the same idea, as you have the button
Advanced. I suppose that when you press this button, a color dialog
could appear in order to select a color in detail. Or do you have
another idea for this button?

===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-28 Thread Thomas Perl

2009/9/28 Piñeiro apinhe...@igalia.com:
 From: Thomas Perl th.p...@gmail.com
 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 very fine. Anyway, you can still use the three column color
 selector and blabla, in order to allow the user to define a custom
 extra color.

 I suppose that you have the same idea, as you have the button
 Advanced. I suppose that when you press this button, a color dialog
 could appear in order to select a color in detail. Or do you have
 another idea for this button?

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 I for example have a great green color
that I want to use for my Uni stuff in GPE, I can have the same color
as background color of Uni-specific notes in Conboy and as background
color for Uni events in the countdown widget, etc..).

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 I for example have a great green color
 that I want to use for my Uni stuff in GPE, I can have the same color
 as background color of Uni-specific notes in Conboy and as background
 color for Uni events in the countdown widget, etc..).

Yes, I totally agree with that. We could just save custom colors to
gconf. That should do the trick :)

I also noticed that it would be nice to have a proper replacement for
GtkAbout dialog - but maybe I should start another thread about this...

Cheers!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
 2009/9/28 Cornelius Hald h...@icandy.de:
  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 I for example have a great green color
  that I want to use for my Uni stuff in GPE, I can have the same color
  as background color of Uni-specific notes in Conboy and as background
  color for Uni events in the countdown widget, etc..).
 
  Yes, I totally agree with that. We could just save custom colors to
  gconf. That should do the trick :)
 
 Here's an updated mock-up:
 
 http://thpinfo.com/2009/maemo/colorchooser2.png

I like the pallet selection!

 Some remarks:
 
  * 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)

Do you think that one custom color is enough? How about having a
complete column or row for custom colors? I didn't try it, but it looks
like there could be enough room for a fourth row of colors. 

  * HildonPickerButton for selecting a pre-set (or application-set)
palette - this would change the displayed colors except the last
column, so we always have black, white and the custom color
 
 Anyone wants to do a mock-up for the advanced color chooser dialog?
 Or propose default color palettes? (If we are going to use something
 like the current mock-ups, we have 3x6 = 18 colors per palette and then
 black and white and the custom color that appears in every palette...)
 
 Also, do we want to have the dialog relayout itself for portrait mode?

I think not in the first version. ATM I know not a single application
that allows editing in portrait mode. Also settings dialogs (where you
often have color selection) are usually landscape only.
If at some point this dialog should support portrait mode, we surely
have to do something about the Done and Advanced buttons as they
already take almost half of the screen width. Also if the pallet-mode
supports portrait, then the advanced-mode should support it too, which
might be even more difficult.

To make it short, I vote for landscape only :)
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-28 Thread gary liquid

On Mon, Sep 28, 2009 at 1:17 PM, Cornelius Hald h...@icandy.de wrote:

 On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
  2009/9/28 Cornelius Hald h...@icandy.de:
   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 I for example have a great green color
   that I want to use for my Uni stuff in GPE, I can have the same color
   as background color of Uni-specific notes in Conboy and as background
   color for Uni events in the countdown widget, etc..).
  
   Yes, I totally agree with that. We could just save custom colors to
   gconf. That should do the trick :)
 
  Here's an updated mock-up:
 
  http://thpinfo.com/2009/maemo/colorchooser2.png

 I like the pallet selection!

  Some remarks:
 
   * 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)

 Do you think that one custom color is enough? How about having a
 complete column or row for custom colors? I didn't try it, but it looks
 like there could be enough room for a fourth row of colors.


full row should fit and in my experience people have a few most recent
selections


   * HildonPickerButton for selecting a pre-set (or application-set)
 palette - this would change the displayed colors except the last
 column, so we always have black, white and the custom color
 
  Anyone wants to do a mock-up for the advanced color chooser dialog?
  Or propose default color palettes? (If we are going to use something
  like the current mock-ups, we have 3x6 = 18 colors per palette and then
  black and white and the custom color that appears in every palette...)
 
  Also, do we want to have the dialog relayout itself for portrait mode?

 I think not in the first version. ATM I know not a single application
 that allows editing in portrait mode. Also settings dialogs (where you
 often have color selection) are usually landscape only.
 If at some point this dialog should support portrait mode, we surely
 have to do something about the Done and Advanced buttons as they
 already take almost half of the screen width. Also if the pallet-mode
 supports portrait, then the advanced-mode should support it too, which
 might be even more difficult.


the standalone dialogs you are used to seeing are normally from desktops and
they have enough space that it doesnt matter

recall however, portrait color selection has been used in paint programs all
the way back to 8bit days - it just wasnt a popup dialog, remember deluxe
paint...

i agree we need to find a really neat way to handle those done/advanced
dialog buttons
the amount of wasted space is silly



 To make it short, I vote for landscape only :)



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.

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?



 Conny


 ___
 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: Community widgets for Fremantle

2009-09-28 Thread Thomas Perl

2009/9/28 Cornelius Hald h...@icandy.de:
 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)

 Do you think that one custom color is enough? How about having a
 complete column or row for custom colors? I didn't try it, but it looks
 like there could be enough room for a fourth row of colors.

With the one custom color I mean a situation like this:

1.) The default color set by the application is #ff (which is not in
 the Tango palette) - default for some setting, not application wide
2.) User clicks on the button that brings up the color selector dialog
3.) The resulting dialog should show a current state, and without the
 single button for #ff added, none of the color buttons could
 be selected.

For the custom colors, I think we can add a whole palette (named
User defined?) to the selection, and let the user customize it. This
User defined palette (again, 18 colors) can then be shared among
applications. It should probably be editable from within the dialog.

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

On Mon, 2009-09-28 at 15:29 +0200, Thomas Perl wrote:
 2009/9/28 Cornelius Hald h...@icandy.de:
  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)
 
  Do you think that one custom color is enough? How about having a
  complete column or row for custom colors? I didn't try it, but it looks
  like there could be enough room for a fourth row of colors.
 
 With the one custom color I mean a situation like this:
 
 1.) The default color set by the application is #ff (which is not in
  the Tango palette) - default for some setting, not application wide
 2.) User clicks on the button that brings up the color selector dialog
 3.) The resulting dialog should show a current state, and without the
  single button for #ff added, none of the color buttons could
  be selected.

Ah ok, now I see and it makes sense to me :)

 For the custom colors, I think we can add a whole palette (named
 User defined?) to the selection, and let the user customize it. This
 User defined palette (again, 18 colors) can then be shared among
 applications. It should probably be editable from within the dialog.

That's another good idea and also prevents the dialog from being too
cramped.

I like it!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 about the
open questions. But from my point of view we need something simple to
start. I still think that a garage project would be best. Then when we
actually have results, we can still discuss what to do with them.

 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 completely sure what you're asking :) Could you elaborate a bit
please.

Thanks!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-28 Thread gary liquid

On Mon, Sep 28, 2009 at 1:48 PM, Cornelius Hald h...@icandy.de 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 live.

 I was hoping that we get some input from the Hildon project about the
 open questions. But from my point of view we need something simple to
 start. I still think that a garage project would be best. Then when we
 actually have results, we can still discuss what to do with them.

  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 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 been added to the dialogs and the api to account for usage
cases.
do we simply draw the line and say, this is a new community dialog library,
or do we go the extra mile and try to accommodate all those little extra
peculiarities which no doubt exist.

gary




 Thanks!
 Conny



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-28 Thread Graham Cobb

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 completely sure what you're asking :) Could you elaborate a bit
 please.

I think Conny's suggestion of a garage project to start with is a good idea.  
Instead of deciding, now, whether these will go into Hildon or be seperate, 
why not develop them initially as pieces of standalone code that people 
include (as source code) into their projects to use, for now?

Then if Hildon adopts them (ideal solution in my mind), the 
CommunityColourSelector would be incorporated into Hildon as a 
HildonColourSelector and people could throw away their copy of the code.

And applications which want to support multiple Maemo versions can use the 
Hildon version if the Hildon library is recent enough or use their own 
private version if not.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle



 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 been added to the dialogs and the api to account
 for usage cases.
 do we simply draw the line and say, this is a new community dialog
 library, or do we go the extra mile and try to accommodate all those
 little extra peculiarities which no doubt exist.

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 namespace is already taken. Therefore I think we
can go with our own API.

Other opinions?
Conny

http://maemo.org/api_refs/4.0/hildon/HildonColorChooser.html
http://library.gnome.org/devel/gtk/unstable/GtkColorSelection.html


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 namespace is already taken. Therefore I think we
 can go with our own API.

OTOH if we expect this to be part of Hildon and we expect it to
_replace_ the current HildonColorChooser it might make sense trying to
be as close as possible to this API. So we just could replace the
implementation be leave the interface. But here my C experience is weak,
so maybe better someone else comment on that :)

Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-27 Thread Thomas Perl

2009/9/26 Graham Cobb g+...@cobb.uk.net:
 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 pure
 white, pure black and a good strong yellow (and a turquiose and a pink would
 be useful).  On the other hand some of the colours look almost identical on
 the screen (particularly 2 of the 3 greens and 2 of the 3 reds -- and who
 needs 6 orangey-browns?).

You can easily replace a column by commenting out (using #) a row of colors
and add something like this (white, black, yellow):

'#ff', '#00', '#00',

 If you are going to have a limited selection, I think they need to be strongly
 contrasting, not shades of similar colours.  My use case is to associate the
 colours with different PIM categories (used for contacts, events, tasks,
 etc.) so people want to have a lot of contrast.

Feel free to search for another color palette, e.g. see this:

http://images.google.at/images?q=color+palette

Maybe something like this would be more suitable?

http://www.newenglandconservatory.edu/styleguide/images/ColorPalette.jpg

You can then edit the file colorchooser.py that I linked above and edit
the HTML hex values and then start the script using python colorchooser.py
to see the results.

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 different shades of grey for some reason).

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-27 Thread Graham Cobb

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 different shades of grey for some reason).

To paraphrase lcuk: yes, yes, yes, yes ... please !

Settable colours are needed, I think and a few pre-defined palettes would be 
awesome.  But if the widget existed I would use it straight away in GPE even 
with a hardcoded palette (I could define the palette for GPE in my copy of 
the widget).  Preferably not using cairo (I do not use cairo in GPE -- I 
think that is because it isn't available in early versions of Maemo).

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-27 Thread gary liquid

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 to quickly select a general colour and then if required
gain access to the more detailed colour wheel and detailed palette.

gary

On Sun, Sep 27, 2009 at 10:29 AM, Graham Cobb
g+...@cobb.uk.netg%2b...@cobb.uk.net
 wrote:

 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 different shades of grey for some reason).

 To paraphrase lcuk: yes, yes, yes, yes ... please !

 Settable colours are needed, I think and a few pre-defined palettes would
 be
 awesome.  But if the widget existed I would use it straight away in GPE
 even
 with a hardcoded palette (I could define the palette for GPE in my copy of
 the widget).  Preferably not using cairo (I do not use cairo in GPE -- I
 think that is because it isn't available in early versions of Maemo).

 Graham
 ___
 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: Community widgets for Fremantle

2009-09-27 Thread Cornelius Hald

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

Very nice and thanks for the demo! I think we would need a way of
supporting different palettes, though. If there are many colors in a
pallet panning still might be a good thing?!
Next question is: Who decides which pallet is used? App-Developer or
user? Personally I think it should be the user otherwise different
applications might provide different pallets and thus confuse the user.
What about adding another button that lets the user choose a pallet? Or
is this too complicated already?

Cheers!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-27 Thread Cornelius Hald

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 same
color several times. Now if you make them smaller and put them closer
together it's almost impossible to select the exact same color several
times.

 i am strongly against panning in a dialog like this though
 there is a time and a place for it and this wouldn't be one 
 
 i also dont think there are any examples of panning color selectors on
 any os

I don't need panning, but I also don't think it would hurt (much). Let's
try doing it without.

 of course, this is only for the easy selector, we seem to agree on the
 dual standard/advanced level stuff.

Yes, a least I like it :)
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-26 Thread gary liquid

On Sat, Sep 26, 2009 at 2:00 PM, Thomas Perl th.p...@gmail.com wrote:

 2009/9/26 Cornelius Hald h...@icandy.de:
  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 top or bottom of
  that list. Maybe separated by some kind of separator.
  8 ---
  When clicking on of those color buttons a dialog like this opens:
  http://zwong.de/wp-content/uploads/2009/09/color_chooser_mock.png
  Probably the buttons/colors should be bigger or there should be 4 in a
  row. As I said, just a very quick mockup. Those buttons are pannable, so
  there are more colors available.

 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



yes, yes, yes, yes, yes 



 Thomas

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-26 Thread 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 colours: it seems to be missing a pure 
white, pure black and a good strong yellow (and a turquiose and a pink would 
be useful).  On the other hand some of the colours look almost identical on 
the screen (particularly 2 of the 3 greens and 2 of the 3 reds -- and who 
needs 6 orangey-browns?).

If you are going to have a limited selection, I think they need to be strongly 
contrasting, not shades of similar colours.  My use case is to associate the 
colours with different PIM categories (used for contacts, events, tasks, 
etc.) so people want to have a lot of contrast.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

RE: Community widgets for Fremantle

2009-09-25 Thread ext-mox.soini


The color wheel might be more understandable to users, yes,
but it's very hard to do a complete color dialog for Maemo 5 and
fit a large finger-usable color-wheel into that space.

It is doable, if you compromise and use stylus instead, but I think
then the whole point of a new widget is lost. You could just use the
existing widget already.

If a new widget is desired to be created, I'd go for a fully finger
usable one, not some halfway deal.

BR,

Mox


-Original Message-
From: maemo-developers-boun...@maemo.org 
[mailto:maemo-developers-boun...@maemo.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 of much use, 
actually. A color wheel would be more understandable.


Martin


2009/9/24, Cornelius Hald h...@icandy.de:
 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 
different 
 styles), only that it does not support images instead it will always 
 show the check box. The check box part (methods/signals) follows the 
 HildonCheckbox way.

 This could maybe be a good example of a widget, that probably won't 
 make it into Hildon as it is 95% copypast code. Also from comments 
 that I got earlier it could be that it is unwanted because 
it does not 
 confirm to some UI guide lines. Well, but it works and I like it :)

 Cheers!
 Conny


 ___
 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

Re: Community widgets for Fremantle

2009-09-25 Thread Piñeiro

From: Cornelius Hald h...@icandy.de

  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?
 
 I think a HildonPickerDialog is probably fine. The distinction between
 the widgets and the dialogs was only made to show that it would be good
 to have both. A widget and a easy way of showing this widget in a
 dialog. How this is solved in details is something for the future. Just
 see this as some vague idea.

Ok

  BTW, as I still think that a future convergence would be a good idea,
  and as a HildonColorChooserDialog exists yet (the deprecated one), I
  would use another name, like HildonExtrasColorPickerDialog (just a
  suggestion).
 
 Convergence would surely rock :)

Cool.

   * HildonExtrasColorChooser:
   A widget that lets the user select a color by only using fingers. I'm
   not yet sure how it should look like, but personally I would like
   something with three color wheels or touch selectors for red, green and
   blue. Then next to it a field shows the composed color of those three
   'color wheels'. Plus an area where you have, for example, the last 8
   used colors.
  
  Hmmm, as far as I see this is just the current (and deprecated)
  HildonColorChooser. What would be the difference? Bigger buttons (to
  be more friendly)? Could you make a mockup?
 
 No, the concept is quite different, but it's difficult to explain. So,
 yes, here is a mockup. But warning: It's ugly! I just spend 5 minutes on
 it, but it should show the concept:
 http://zwong.de/wp-content/uploads/2009/09/color.png

Ok, as far as I see is similar to the proposal I made (see later).

  AFAIR, when we were talking about that, me (or Claudio) suggested a
  friendly-finger touch-selector, with a limited amount of colors
  predefined.
 
 Possible, but maybe to limited?!

Yeah, probably this could be good to just select the predefined
colors, but not to select *any* color.

  Other option could be a three column (red+green+blue) touch-selector,
  that allows you to select the mixture you want.
 
 I think that's more or less how my mockup works :)

Yes, and in fact, we can modify the granularity of each basic color
column, like HildonTimeSelector does with the minutes (see property
minutes-step).

  BTW: the problem that I found to hildon-extras name is that is too
  long ;) HildonExtrasFontSelector seems too long for me. I would prefer
  a name for the library, probably with a H to infer that is Hildon
  related (like HAIL-Hildon Accessibility Implementation Library), what
  about Hexy? (Hildon Sexy), so HexyColorButton and so on. But this is
  just a question of taste.
 
 Something short then HildonExtras would be nice. 'Hexy' would be fine
 for me.
 
 Thanks for your input and keep on discussing :)
 Conny

Ok, it seems that this library will finally be created, I suppose that
the next to be discussed is the name, Hexy was just quick suggestion ;)

===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-25 Thread Murray Cumming

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+ widgets that are not supported on
Maemo, I'd rather just see the Maemo GTK+ port improved. We don't need
more unnecessary ifdefs in our applications.


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-25 Thread Martin Grimme

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 in the backgroud, so that the
user sees where the colors are. The V slider could then show the
gradient for that color, and the S slider the saturation.

Don't get me wrong, RGB is fine and this is what I prefer, but it's
not obvious to use for a regular user, so we need some alternative way
of finding colors.


Cheers,
Martin
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-25 Thread gary liquid

there is an lot of very good dialog here :)


On Fri, Sep 25, 2009 at 9:14 AM, Murray Cumming murr...@murrayc.com 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 available, but they
  are not fully finger-friendly or don't look good.



and this was the kickstart of the whole discussion a few days ago :)
fiferboy came to a section in his program where he needed a font dialog and
we all started talking in irc.


whatever project and choices we organise now would be a hotbed of ideas for
practical usable handheld finger friendly components but at the same time we
must have a rapid and sustainable process to take the best of these ideas
and concentrate efforts in getting stable end developer ready components
quickly in whichever end library we decide.

there is already fragmentation in the standard controls with font handling
especially and this means end users will already have a different experience
depending on the app chosen.


 When this is just about regular GTK+ widgets that are not supported on
 Maemo, I'd rather just see the Maemo GTK+ port improved. We don't need
 more unnecessary ifdefs in our applications.



the most serious issue I see with that approach is needing to remain fully
and completely API compliant with the standard dialogs - which is where the
developer staying power comes from.
its easy to create new glossy front ends for specific use cases, but to have
a rounded feature complete bug tested component which accounts for all the
standard options and which replicates the subtle bugs usually makes things
difficult.

There is a long history of expansion libraries for GTK, some have lived
longer than others - Hildon stands up as a successful expansion and whilst
we are all aware of its limitations believe the experience and knowledge
that the library has will be invaluable.


I would suggest one thing with any test code we create in garage
to ensure developers do not get the wrong idea, we should not really make it
a library..
just a test app with a palette of test screens and dialogs that can be
worked on
developers should not tie themselves to this initial library and the
temptation will be great and we will get into a mess very quickly and upset
people who pickup the components too early because of buzz about their
utility and impressive attributes ;)

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 within the dimensions.
perhaps taking a look at how that works and whether its usable in Fremantle
would be beneficial.

Gary





 --
 murr...@murrayc.com
 www.murrayc.com
 www.openismus.com

 ___
 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: Community widgets for Fremantle

2009-09-25 Thread Thomas Perl

2009/9/25 gary liquid liq...@gmail.com:
 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 within the dimensions.
 perhaps taking a look at how that works and whether its usable in Fremantle
 would be beneficial.

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 of green, but just getting a cute color that happens
to be green. A nice palette with beautiful colors can help here.

I propose a dialog with finger-usable buttons that just has the colors of the
Tango Color Palette in it:

http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines

Give the users less choice and more sane defaults ;) You can always add
that Advanced button with a hex entry field for the nerds later on.

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Community widgets for Fremantle

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 have lots of duplicated work and
inconsistent behavior between different applications.

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.

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
HildonExtrasColorChooserDialog is opened.

* HildonExtrasColorChooserDialog:
A dialog that displays a HildonExtrasColorChooser.

* HildonExtrasColorChooser:
A widget that lets the user select a color by only using fingers. I'm
not yet sure how it should look like, but personally I would like
something with three color wheels or touch selectors for red, green and
blue. Then next to it a field shows the composed color of those three
'color wheels'. Plus an area where you have, for example, the last 8
used colors.

* HildonExtrasFontSelectionDialog:
A dialog that lets the user select font face and size. Maybe also font
style (bold, italic, ...), color and other things.

* HildonExtrasCheckButton:
A button with two labels like a normal HildonButton, but with a check
mark on the left like a HildonCheckButton. So basically a
HildonCheckButton with two labels. (I'll do that if no one minds).


There are probably more widgets, so feel free to write about your ideas
and how you think that some widgets should look and behave. Also of
course, those names and ideas are not fixed - nothing is fixed, it's
just a very early proposal. I just felt, like we should discuss this
here, visible for everyone because there have been some discussion about
that issue already in other places.


So who is interested? Who wants to provide code or mockups? Ideas?
Critics? Flames? Let the ideas roll :)

Cheers!
Conny



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-24 Thread 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 why you need a new library. We've proposed already in the
past to the community the possibility to work together in the missing
widgets, specially these you mention. We have no problem on pushing
these widgets to Hildon if you are willing to contribute.

Anyone with patches and/or good mockups is free to join
hildon-de...@garage.maemo.org and to attach these in Bugzilla. We'll
review patches as time allows (and will probably have more time to help
soon).

Claudio


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-24 Thread Piñeiro

From: Cornelius Hald h...@icandy.de

 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 picker. But I dont find the exact place :P

As far as I remember, the conclusion was that that widgets are
interesting, on hildon itself, but nobody has time to do that at that
time, due time restraints and priorities.

 Developers are expected to implement those widgets by them selfs which
 could lead us to a situation where we have lots of duplicated work and
 inconsistent behavior between different applications.
 
 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.

Well, I suppose that you are thinking in something like libsexy [1], a
more-flexible library to put shared effort. Anyway, as I said,
probably all this widgets can have a place inside hildon. Would you
like that in the future this widgets would be moved to Hildon or you
prefer a differen approach?

 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
 HildonExtrasColorChooserDialog is opened.

So in this case, at least in the behaviour, is more similar to the
HildonTimeButton or HildonDateButton, but showing a square with the
color, instead of the value string. Right?

 * HildonExtrasColorChooserDialog:
 A dialog that displays a HildonExtrasColorChooser.

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?

BTW, as I still think that a future convergence would be a good idea,
and as a HildonColorChooserDialog exists yet (the deprecated one), I
would use another name, like HildonExtrasColorPickerDialog (just a
suggestion).

 * HildonExtrasColorChooser:
 A widget that lets the user select a color by only using fingers. I'm
 not yet sure how it should look like, but personally I would like
 something with three color wheels or touch selectors for red, green and
 blue. Then next to it a field shows the composed color of those three
 'color wheels'. Plus an area where you have, for example, the last 8
 used colors.

Hmmm, as far as I see this is just the current (and deprecated)
HildonColorChooser. What would be the difference? Bigger buttons (to
be more friendly)? Could you make a mockup?

AFAIR, when we were talking about that, me (or Claudio) suggested a
friendly-finger touch-selector, with a limited amount of colors
predefined.

Other option could be a three column (red+green+blue) touch-selector,
that allows you to select the mixture you want.

(This touch-selector approach could be called
HildonExtrasColorSelector, for example)

 * HildonExtrasFontSelectionDialog:
 A dialog that lets the user select font face and size. Maybe also font
 style (bold, italic, ...), color and other things.

As I said before, why it is required a specific Dialog?

So I would bet for a HildonExtrasFontButton and a
HildonExtrasFontSelector. So the button just open a
HildonPickerDialog, and put inside a HildonFontSelector, like the
current HildonDateButton-HildonDateSelector.

 * HildonExtrasCheckButton:
 A button with two labels like a normal HildonButton, but with a check
 mark on the left like a HildonCheckButton. So basically a
 HildonCheckButton with two labels. (I'll do that if no one minds).

 There are probably more widgets, so feel free to write about your ideas
 and how you think that some widgets should look and behave. Also of
 course, those names and ideas are not fixed - nothing is fixed, it's
 just a very early proposal. I just felt, like we should discuss this
 here, visible for everyone because there have been some discussion about
 that issue already in other places.

Well, as I said, this is a good idea if you think in something like
libsexy, in order to have ASAP a place to put this widgets, and the
future plan is integrate this widgets or features on Hildon. As we
talked before, I agree that give Fremantle-like equivalent widgets to
the Hildon 1.0 deprecated widgets is a good idea, and a good idea to
put that on Hildon.

BTW: the problem that I found to hildon-extras name is that is too
long ;) HildonExtrasFontSelector seems too long for me. I would prefer
a name for the library, probably with a H to infer that is Hildon
related (like HAIL-Hildon Accessibility Implementation Library), what
about Hexy? (Hildon Sexy), so HexyColorButton and so on. But this is
just a question of taste.

 So who is interested? Who wants to provide code or mockups? Ideas?

Re: Community widgets for Fremantle

2009-09-24 Thread Piñeiro

From: Andrew Olmsted andrew.olms...@gmail.com

 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.

Looking at the pannable-font-selector, it seems another
HildonTouchSelector subclass. In this case, like the time selector and
date selector, I suggest to avoid to use the pannable prefix, as IMHO,
is confusing, as it seem to suggest a pannable modification. In the
same way, normally on gtk and hildon (and nome libraries in general),
the prefix are used to put the name of the library.

For this cases I would use something like:
libraryname-font-selector.c and libraryname-color-selector.c.

BR

===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-24 Thread Piñeiro

From: Claudio Saavedra csaave...@igalia.com

 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 proposed already in the
 past to the community the possibility to work together in the missing
 widgets, specially these you mention. We have no problem on pushing
 these widgets to Hildon if you are willing to contribute.
 
 Anyone with patches and/or good mockups is free to join
 hildon-de...@garage.maemo.org and to attach these in Bugzilla. We'll
 review patches as time allows (and will probably have more time to help
 soon).

Answering myself and Claudio: and of course this is just the other
option, and probably the most straighforward.

Because although Cornelius, you have asked about the color
replacements and so one, and you asked some current Hildon developers
about that, that you were creating this new widgets are new for us,
and probably would be great to just upload some patches on the
bugzilla, instead of just start a new library with them.

===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

2009-09-24 Thread Andrew Olmsted

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 hildon code, so 
hopefully they will be easy to integrate (if it is decided they are good 
enough).  The only thing I am not sure about is naming.  I will keep 
them with their current names for now - if should be easy enough to 
rename them later.

Thanks,
Andrew

Claudio Saavedra wrote:
 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 proposed already in the
 past to the community the possibility to work together in the missing
 widgets, specially these you mention. We have no problem on pushing
 these widgets to Hildon if you are willing to contribute.

 Anyone with patches and/or good mockups is free to join
 hildon-de...@garage.maemo.org and to attach these in Bugzilla. We'll
 review patches as time allows (and will probably have more time to help
 soon).

 Claudio


 ___
 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: Community widgets for Fremantle

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
grateful for this. If it was received like this, I'm really sorry.

And yes, we talked about color/font choosers already but there have been
no actions. No one had time and I was also doing nothing.
Some days ago the issue came up again in a private discussion, so I was
just thinking we should give it another try. Because, the fact remains
that some of us need/want composite widgets like color/font choosers and
it would be a shame if we duplicate work.

I know you are also open for patches and I'm sure you'll do your best to
include these into Hildon. Of course it would be the best solution to
integrate the community widgets directly with Hildon and this should be
the goal.
But I'm quite sure that, for example, my code wouldn't pass your quality
assurance easily. I'm still quite new to all this stuff and I might just
produce poor code which needs a lot of work or testing.

Because of this I think we should have a garage project which acts as an
incubator for the real thing. It should be super easy to commit code and
to try out the code of others. Now, once a widget in the 'incubator' has
matured enough it could easily be pulled into Hildon and have a happy
life there :)
Whether or not it makes sense to create a library out of the 'incubator'
code or if it should be source only is debatable. I personally don't
care much. For me it's just important that we have a easy way of
sharing. Without bureaucracy or high entry barrier.
Also there might be widgets that you don't want to have in Hildon. There
might be quality concerns or style concerns. I think those widgets still
should have a home. They might be useful for one or two developers.

This was/is really only a proposal. I for myself have not done anything
yet (ok, a bit but not much). So I've not written any color or font
chooser. I just wanted to start the discussion again and see what people
are thinking. And as it turned out Andrew already has some code and is
willing to share that - which is very nice!


So what do you think? Is it a good idea to have an 'incubator'? Should
it be source only or should it include releases as libs?
Are more people interested? Which other widgets do you think are
missing?

There are some more things which I'll answer soon in separate mails :)

Thanks for the discussion!
Conny



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 different
styles), only that it does not support images instead it will always
show the check box. The check box part (methods/signals) follows the
HildonCheckbox way.

This could maybe be a good example of a widget, that probably won't make
it into Hildon as it is 95% copypast code. Also from comments that I
got earlier it could be that it is unwanted because it does not confirm
to some UI guide lines. Well, but it works and I like it :)

Cheers!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

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 possible for the user.

that's great news :)

 Both widgets are in their early stages, but suggestions are certainly
 welcome.  I wasn't sure whether using hildon in the name of a
 non-official widget would be okay.  Is there a precedent for that?

I don't think that Hildon is a trademark, but probably API and Claudio
can comment on this. For now I think the name is not that important.
Renaming is still possible later.

 I'm not sure what the best way to collaborate would be.  Thus far IRC
 has been good, but I don't want to exclude anyone.  Maybe using this
 mailing list and IRC in tandem is the best idea.

Well, personally I'm never on IRC. So for me mailing list would be best.

 If you want to see what I have so far, the font selector can be seen
 here:  http://andrew.olmsted.ca/maemo/screens/snapshot39.png

I already like it, as it is definitely finger-friendly which is IMO very
important. Maybe it would be possible to render the font names already
with the actual font? I think that would look nice and gives automatic
preview.

 What I have for colour selector:
 http://andrew.olmsted.ca/maemo/screens/snapshot40.png

I like this one too. Some suggestions:

- If the sliders widgets would be colored red, grenn and blue, there
would be no need for the labels anymore. Unfortunately I think it's
impossible :(

- A small number of favorite colors would be nice too.


Thanks a lot for sharing these :)
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle