headers
Shaun McCance | 1 Oct 2008 01:01
Picon
Gravatar

Re: Testing dark themes and marking deprecated widgets

On Tue, 2008-09-30 at 12:31 +0200, Benjamin Berg wrote:
> Hello,
> 
> There have been ideas to improve the desktop by modifying the themes to
> show problems in application. Specifically I am proposing to use a dark
> colour scheme for Clearlooks during the next unstable release cycle.
> Another idea is to highlight deprecated widgets in applications, by
> changing their colour to be eg. some shade of red.
> 
> By using a dark colour scheme problems with applications that are using
> the wrong colours for text can be exposed. Turning Clearlooks to a dark
> colour scheme would mean that a lot more applications can be tested and
> both the application and the themes can be fixed.
> 
> The idea to change the colour of deprecated widgets is to expose any
> application that is still using them. This would hopefully encourage
> maintainers and others to write patches and port applications to use
> non-deprecated widgets.
> 
> Both of these changes would be reverted in time for the first beta
> release of GNOME (due on February 4th). If this is implemented, we would
> probably also have a "Clearlooks Stable" theme, so that it is still
> possible to use the normal Clearlooks theme for eg. documentation
> purposes.
> 
> 
> Do you think that exposing deprecated widgets and theme related bugs
> like this is a good idea?

How many people test the unstable releases using an existing user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sven Herzberg | 1 Oct 2008 13:24
Gravatar

Re: [Fwd: [Evolution-hackers] Evolution: Taking forward...]

Hi,

Am Freitag, den 26.09.2008, 10:52 +0200 schrieb Mikael Hallendal:
> > Hello guys,
> >
> > We have had a set of problems that we are carrying around for some  
> > time like :
> >
> >      * Copyright assignments, which is not the best way looking for  
> > the future of Evolution. It sucks and sort of limits contributions  
> > to Evolution and we wanted to drop it.
> >      * The current licensing incompatibility issues of Evolution  
> > with Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/ 
> > samba4 for the new mapi based connector being developed for Exchange  
> > 2007.
> >
> > So here is the plan :
> >
> >      * Drop Evolution copyright assignments and make it really easy  
> > to contribute to Evolution
> >      * Move Evolution licensing to  "LGPL v2 and LGPL v3" to let us  
> > re-use the code more easily around the platform.  This also moves us  
> > closer to Thunderbird's MPL/LGPL model.

Feel free to use my code under the terms of "LGPL 2.1 and (at your
option) any later version".

Regards,
  Sven
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Larsson | 1 Oct 2008 14:13
Picon
Favicon

eel and nautilus branched

I've branched eel and nautilus for Gnome 2.24. gnome-2-24 is for
translations and bugfixes only. New features goes on trunk.
Permalink | Reply | 2 comments |
headers
Alexander Larsson | 1 Oct 2008 14:51
Picon
Favicon

libunique external dependency for 2.25?

I just commited some nautilus code to trunk (for 2.25) that makes use of
libunique for unique application functionallity (replacing the previous
code using bonobo-activation). 

However, libunique isn't currently a blessed external dependency. So,
I'd like to propose it. (Another alternative is to put a cut-n-paste
copy in nautilus as fallback, its not a large piece of code anyway.)
Permalink | Reply | 11 comments |
headers
Hubert Figuiere | 1 Oct 2008 15:29
Gravatar

Re: libunique external dependency for 2.25?

On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote:
> I just commited some nautilus code to trunk (for 2.25) that makes use
> of
> libunique for unique application functionallity (replacing the
> previous
> code using bonobo-activation). 
> 
> However, libunique isn't currently a blessed external dependency. So,
> I'd like to propose it. (Another alternative is to put a cut-n-paste
> copy in nautilus as fallback, its not a large piece of code anyway.)

Can't we add that to Gtk+ ?

Hub
Permalink | Reply | 0 comments |
headers
Gil Forcada | 1 Oct 2008 15:46
Picon
Gravatar

Re: eel and nautilus branched

Hi!

l10n.gnome.org updated!

Cheers,

El dc 01 de 10 de 2008 a les 14:13 +0200, en/na Alexander Larsson va
escriure:
> I've branched eel and nautilus for Gnome 2.24. gnome-2-24 is for
> translations and bugfixes only. New features goes on trunk.
> 
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n <at> gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
--

-- 
gil forcada

[ca] guifi.net - una xarxa lliure que no para de créixer
[en] guifi.net - a non-stopping free network
bloc: http://gil.badall.net

_______________________________________________
gnome-i18n mailing list
gnome-i18n <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Permalink | Reply | 0 comments |
headers
Richard Hughes | 1 Oct 2008 18:51
Picon

Re: libunique external dependency for 2.25?

On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote:
> I just commited some nautilus code to trunk (for 2.25) that makes use
> oflibunique for unique application functionallity (replacing the
> previous code using bonobo-activation). 

I already use conditionally in gnome-power-manager and gnome-packagekit.

Richard.
Permalink | Reply | 3 comments |
headers
Alexander Larsson | 1 Oct 2008 19:09
Picon
Favicon

Re: libunique external dependency for 2.25?

On Wed, 2008-10-01 at 17:51 +0100, Richard Hughes wrote:
> On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote:
> > I just commited some nautilus code to trunk (for 2.25) that makes use
> > oflibunique for unique application functionallity (replacing the
> > previous code using bonobo-activation). 
> 
> I already use conditionally in gnome-power-manager and gnome-packagekit.

Oh? Then what do you do if its not there? I'd rather not make
unique-application functionallity optional, and while i could re-code
the grotty dbus and startup notification stuff that libunique does
myself I don't quite see the point.
Permalink | Reply | 2 comments |
headers
Stefan Kost | 1 Oct 2008 22:45
Picon
Gravatar

Re: Testing dark themes and marking deprecated widgets

hi,
Benjamin Berg schrieb:
> Hello,
> 
> There have been ideas to improve the desktop by modifying the themes to
> show problems in application. Specifically I am proposing to use a dark
> colour scheme for Clearlooks during the next unstable release cycle.
> Another idea is to highlight deprecated widgets in applications, by
> changing their colour to be eg. some shade of red.
> 
> By using a dark colour scheme problems with applications that are using
> the wrong colours for text can be exposed. Turning Clearlooks to a dark
> colour scheme would mean that a lot more applications can be tested and
> both the application and the themes can be fixed.
> 
> The idea to change the colour of deprecated widgets is to expose any
> application that is still using them. This would hopefully encourage
> maintainers and others to write patches and port applications to use
> non-deprecated widgets.

Good idea. On dark-theme bug that exists for quite some time already and that
e.g. forces apps like ardour into using an own theme is:
http://bugzilla.gnome.org/show_bug.cgi?id=382646

On a slightly related notes, what about my proposal in
http://bugzilla.gnome.org/show_bug.cgi?id=524966
That could help developers to understand what colors are used.

Stefan
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hughes | 2 Oct 2008 13:55
Picon

Re: libunique external dependency for 2.25?

On Wed, 2008-10-01 at 19:09 +0200, Alexander Larsson wrote:
> Then what do you do if its not there?

Don't do any of the unique application bits, i.e. start up another
instance of the prefs capplet regardless.

Richard.
Permalink | Reply | 1 comment |

Gmane