Re: intltool move

[Rodney Dawes]

On Thu, 2009-05-07 at 22:10 +0200, Christian Rose wrote:
> On 4/24/09, Rodney Dawes  wrote:
> > On Fri, 2009-04-24 at 03:59 +0200, Vincent Untz wrote:
> >  > Le dimanche 19 avril 2009, à 15:25 -0400, Rodney Dawes a écrit :
> >  > > The intltool product on bugzilla.gnome.org is now closed for new
> >  > > reports, and the SVN module was moved over to svn-archive before the
> >  > > gnome.org transition to git. The latest intltool code is already in a
> >  > > bzr branch on Launchpad (lp:intltool) and, all new bugs should be
> >  > > reported at http://bugs.launchpad.net/intltool/ from now on. There are
> >  > > still a few open bugs in bugzilla, which Danilo or myself will deal
> >  > > with as appropriate, by fixing, moving, or closing as wontfix.
> >  >
> >  > Going to https://bugs.launchpad.net/intltool/+filebug, I get:
> >  >
> >  > "intltool does not use Launchpad as its bug tracker."
> >
> > Doh. Sorry about that. Should be fixed now.
> 
> By the way, is there an intltool homepage? The page
> http://www.freedesktop.org/wiki/Software/intltool does not seem to
> have updated info.

I totally forgot that page existed. http://launchpad.net/intltool is
the real home page now. I've updated the fd.o wiki page as well to point
to appropriate URLs. Thanks for reminding me!


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

External dependency: icontool

[Rodney Dawes]

Hi,

Currently, we are using icon-naming-utils in gnome-icon-theme to create
the backwards-compatible symlinks for icons. However, I've created the
icontool [1] project to subsume this task, as well as provide useful
tools for managing other aspects of themes and icons in applications. As
part of that, there is also now the icontool-render script, which takes
a single-canvas SVG [2], and generates individual PNG images of the
icons contained within it. This single-canvas workflow makes it much
easier to maintain icons in themes and different projects.

As such, I would like to have icontool be a blessed external dependency
in GNOME 2.27+, so that we can switch to using it in gnome-icon-theme,
for maintaining the compatibility symlinks, and rendering icons from the
single canvas SVGs, which we intend to migrate to in the relatively near
future, for all the icons in gnome-icon-theme.

Thanks!
-- Rodney

[1] http://launchpad.net/icontool
[2] http://jimmac.musichall.cz/i.php?i=git3


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bump intltool version to 0.41.0

[Rodney Dawes]

On Wed, 2010-02-24 at 13:51 +0100, Luca Ferretti wrote:
> A final note: Rodney, could you please upload 0.41 to
> http://ftp.gnome.org/pub/GNOME/sources/intltool/ ?

The canonical location for intltool tarball downloads is:
https://launchpad.net/intltool/+download



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Possible Translation Conditions in Code

[Rodney Dawes]

I have been looking at bug #386118 [1] recently, as it seems like an
important issue to me, and is relatively easy to fix. When looking over
the patch, and the issue originally reported, I discovered that we suck
for translation detection in C files much worse than the bug implies.

So, that brings us to you, the developers. I have a patch which
currently fixes things up with the following regular expression:

/[\s\(\{\:\?\=,][NQ]?_ *\(QUOTEDTEXT/

My question is if there are any other conditions that we need to
check for, so that we don't claim files need translations, when
they don't (if someone defines a FOO_ macro that operates on strings,
for example). I think this covers pretty much all of the cases that
we have. If others could please send me issues where the above
expression doesn't work, so that I could add them in, that would
be great.

I've also attached a patch [2], so that people can easily test
this issue. If people could thoroughly test it, so that I can get
any remaining cases fixed, and get a release out with this fix,
that would be great as well.

Thanks.

-- dobey

[1] http://bugzilla.gnome.org/show_bug.cgi?id=386118
[2] http://bugzilla.gnome.org/attachment.cgi?id=78601&action=view


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Subversion migration finished

[Rodney Dawes]

It would be nice if CVS were at least able to be used read-only, so that
those of us with changes in our local trees, can ensure that we're up to
date with the final point of CVS, and can generate diffs to apply
against SVN when migrating local checkouts.

-- dobey


On Mon, 2007-01-01 at 11:54 +, Ross Golder wrote:
> For those that haven't noticed, the subversion migration is now
> complete. In the end, it took about 49 hours. Apologies for the downtime
> involved.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 14:28 +, Bill Haneman wrote:
> As far as I know, gnome-main-menu hasn't had a thorough accessibility 
> review.  As such, I'd be very wary of introducing it this late in the 
> release cycle.Shouldn't we have this discussion near the beginning 
> of the cycle (say, 2.19.1) ?

The modules get proposed near the beginning of the cycle, and gives one
plenty of time to discuss them. In fact, I recall there was a nice big
flame war about whether or not it should replace the existing menus.

That said, I personally have put quite a lot of work into making the
main menu be accessible. There might be a couple of minor pieces in the
application-browser and control-center shell apps that need tweaked, but
overall it is quite accessible.

I've also written a suite of scripts to allow us to gauge the level of
support for accessibility in the desktop, which I feel have not gotten
the level attention that they deserve. These scripts really need to get
run and updated all the time. If some piece of UI changes in an
application, it can easily cause the script to stop working. It would
be really nice if we could get these scripts to be run automatically
by jhbuild in the tinderbox, so that we can ensure our desktop is
accessible, and that the scripts stay up to date, to avoid failures.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 13:59 +0100, David Prieto wrote:
> > Mine has this ("recently used apps" menu).
> 
> I'm sure you must mean a favourite apps menu, not recently used.
> 
> Otherwise please, correct me.

It has Favorite Apps, Recent Apps, and Recent Documents. For Recent Apps
to work, however, it requires minor changes to the recent files
implementation, to support the listing of applications. It is possible
that you aren't getting that, if you don't have the patch applied.

However, I hardly think this should be a showstopper for inclusion,
given that the current menus don't have Recent Apps.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 14:37 +0100, David Prieto wrote:
> > it does that but using beagle, if available, AFAIK.
> 
> Well, that's not what I meant then.
> 
> Accessing an app through the "more apps" menu is painfully slow and
> intrusive if you know what specific app you want to run, but it happens
> not to be on your favourites menu.

The Alt-F2 keybinding still works, so you can easily run apps without
having to open the more applications, or beagle search, UIs. Perhaps
we need to add a little "Run..." button under the "System" group on
the right side of the main menu, but the functionality is still
there. It's no slower than having to search through a large menu, when
menu items may move. The "more apps" browser has an application filter
entry, that compares against more than just the Name field of the
application's desktop file. If the complaint of slowness is purely
on the fact that it might take a second to open initially, then the
answer is simply that it needs a little performance work, which as
I understand, is being worked on, or will be soon enough. The slow
initial run is almost entirely disk i/o bound.

> The search bar could easily solve that by doing an app search and
> offering the user to open it right away. But opening a beagle search
> window is even worse than the initial situation.

It doesn't have to open beagle. It can open whatever you tell it to,
via the gconf key. The same with the package manager integration. It
doesn't have to use what the current defaults are. It can use whatever
nifty package management tools you want it to.

Are you proposing to integrate the functionality of deskbar into the
main menu applet, and thus replace deskbar as well? That's what I'm
getting from your comments, anyway.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 09:27 +1300, John Stowers wrote:
> +1
> 
> I find gnome-main-menu pleasant to use.
> 
> >From a feature parity perspective I think KDE is shipping their fancy
> new menu thing in KDE4 so it may be good to have something comparible
> in GNOME. Yes feature copying is not always the answer but its easier
> to say "yes GNOME has that" then it is to explain why  the current
> style menu is better etc.

Given that we aren't the copy, I think it's fair to say that's not an
issue. :)

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 17:44 +, Bill Haneman wrote:
> Since there was a lot of a11y work in the existing menu code, I doubt 
> that g-m-m would "just work" for all of our a11y scenarios without 
> bugfixes/tweaks.

Can you explain those scenarios? As I said in a previous reply, I spent
a lot of time making a11y in the main-menu work. If there are specific
scenarios that we need to check for, then we should get those formalized
into a test suite somewhere, and get the tests run on all our apps.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 15:48 -0500, Bryan Clark wrote:
> Personally I think the menu is nice and there are a number of things I'd 
> have done differently but the main reason I see against including it is 
> that without beagle I can't imagine using it. I tried turning off beagle 
> and it's pretty hard to navigate your files without a places menu. Any 
> suggestions?

I think this example you bring up here, is a shining point of why we
need beagle (or tracker, or anything else) in the desktop. The fact that
it is hard to navigate your files without bookmarks to the folders that
contain them, is a pretty big usability problem, especially considering
that everything we care about, is a file.

Perhaps we should also look at how people use the places menu, and why
they find it so necessary to have. Personally, I never use the places
menu, as it doesn't fit how I use my computer. I am not sure that any
of the larger market of users would either. It seems like a hacker
feature to me.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 21:26 +0100, Steve Frécinaux wrote:
> Well, IMHO, slowness and relevance of information is not that stylistic 
> (since the later can be easily fixed, I'm less sure about the second), 
> and coherence and consistency are not that minor. And we are in freeze, 
> aren't we ? So it could be a bit late if there are something to changes.

It's slow on FIRST RUN. Subsequent runs are pretty much instantaneous.
The panel is also slow to start up. When you have to load a hundred or
so files off disk, and parse them all, there's going to be some
slowness. The panel appears less slow, because you're not *starting*
the menu during your session. It's already running, and the slowness
is at startup of the session, rather than when pressing the menu icon
on the panel.

It follows the theme colors. If you don't like the colors change your
theme, or fix the theme to make them different colors. This is in fact
one of the requirements we put on the main menu, when writing it.

Both of the issues you're complaining about, can be fixed. And in fact,
they aren't that hard to fix. They just take a little time to fix.

-- dobey



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Wed, 2007-01-10 at 11:12 +1300, John Stowers wrote:
> Could not agree more regarding the importance of an indexing searcher
> to the GNOME desktop.
> 
> Because tracker is also being proposed for inclusion could the slab
> hackers comment on how pluggable the beagle search features in slab
> are and how easily it could be substituted for tracker based ones?

All the slab does is run beagle-search "string", and I believe,
beagle-search is specified via a gconf key. It would be trivial to
change the key, or code to support a key if it doesn't already.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[Rodney Dawes]

On Tue, 2007-01-09 at 23:20 +, Jamie McCracken wrote:
> Its sheer madness to say we dont need them tightly integrated into our 
> desktop especially when you look at OS/X and Vista. Gnome aspires to be 
> the best desktop so we need to stop holding back things and have a 
> little faith in these promising new technologies (even if they are not 
> perfect yet)

I don't think anyone is saying that we DON'T need them. I'm sure most
people agree that we do need good search integrated into the desktop.
As others have stated, I don't think either beagle or tracker is at
that point yet. Out of all the things GNOME may claim to need on the
desktop, the first and foremost thing it needs, is users. Without that,
it doesn't matter what software we have. Having either beagle or tracker
is not going to get us a significant increase in user base.

> I would also add that nautilus search without beagle or tracker is 
> barely usable and appallingly slow so its not only the new menu thats 
> suffering here.

One shining point in usability testing, when we were working on where to
put the Search entry, was that users actively avoid doing search, and
resort to other methods to find files, such as simply browsing. This is
not because beagle, tracker, or anything else are especially horrible
today, but rather because past experiences with other search methods
(primarily the standard find files in windows), has resulted in very
poor results.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Not my Favorite [was Re: Proposed module: gnome-main-menu]

[Rodney Dawes]

But they aren't the user's bookmarks. Perhaps it would be better if we
just removed the term Favorites.

-- dobey


On Thu, 2007-01-11 at 16:22 +, Alan Horkan wrote:
> In technical terms it is dissapointing that GTK does not have a stock menu
> item for Bookmarks because if it did we could at least make a change and
> use Favorites consistently instead of Bookmarks (and maybe the term
> Launchers too) but dissapointingly Novell seem unwilling to avoid
> introducing this bit of inconsistent terminology.  (I'm not unwilling to
> provide a patch against the version in Gnome CVS but it doesn't seem like
> that would be helpful.)
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application specific themable icons

[Rodney Dawes]

This got sent before I was finished. Sorry about that. Butterfingers.


On Sat, 2007-01-13 at 20:13 +0300, Nickolay V. Shmyrev wrote: 
> Since I've now meet this problem in evince bug 
> http://bugzilla.gnome.org/show_bug.cgi?id=386226
> let me complain about new way too. For other complains one can also read
> http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00302.html 
> http://mail.gnome.org/archives/desktop-devel-list/2006-February/msg00024.html
> http://mail.gnome.org/archives/desktop-devel-list/2006-July/msg00797.html
> as Luca kindly mentioned. 
> 
> Looking at Epiphany specific icons I don't quite understand why "download" or 
> "bookmark-view" 
> is Epiphany specific icon. Also I don't understand why quite ugly looking 
> icon for 
> sidebar should be evince specific.

Because these icons are specific to epiphany. We don't have desktop-wide
bookmarks, that integrate all the various types. The bookmarks in
epiphany, are quite different from those in nautilus, which may be
different from those shown in the file chooser. Download I admit, is not
specific to epiphany. In fact, download and save are the same action, and
should not have different icons. However, I'm sure plenty of people will
also disagree with that, hence the reason that epiphany seems to need a
download icon.

> I dislike the need to install all icons into ${datadir}/hicolor/... and don't 
> see how it
> will improve consistent look of the desktop. I understand that it's hard to 
> maintain large
> set of icons in gnome-icon-theme, but nobody tells maintaince is an easy 
> thing. So if you'd
> like to have small subset, you can just split icon-theme in two packages - 
> maintained and
> unmaintained one.

So applications will have to depend on the "extra" package, to even be
functional? I don't think so. Nobody wants that.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application specific themable icons

[Rodney Dawes]

On Sun, 2007-01-14 at 18:51 +0100, Vincent Untz wrote:
> Le samedi 13 janvier 2007, à 20:13, Nickolay V. Shmyrev a écrit :
> > I dislike the need to install all icons into ${datadir}/hicolor/...
> 
> This made me read http://live.gnome.org/ThemableAppIcons and I'm now
> wondering about one thing...
> 
> The path where apps install icons is $(pkgdatadir)/icons/hicolor. I
> guess this path is chosen to avoid conflicts between icons of various
> applications. However, how does this work for icon themes you download
> and put in ~/.themes/$(name)/icons/? I mean, the name clash for icons of
> various apps that the theme author wants to theme will appear there too.

There will be a metaphor clash, yes, but this just needs to be worked
out between the applications, so that the icons are used properly. This
is no different than current cases where we have people copying icons
to different names, just so they can have an icon for something in their
UI. It's just abusing the icons. For using icons properly, there is
plenty of UI review that can, and needs, to be done.

The benefit here is that while the above is true, you don't have
multiple apps installing the same file name to the system hi-color
theme, creating file conflicts and packaging problems for vendors.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application specific themable icons

[Rodney Dawes]

On Mon, 2007-01-15 at 10:57 -0600, Shaun McCance wrote:
> On Fri, 2006-12-15 at 11:49 +0100, Luca Ferretti wrote:
> > Here [1] is a page about application specific themable icons (named
> > icons installed by application outside the system-wide hicolor
> > directory).
> > 
> > Feel free to edit (by now it's just a draf), implement suggested changes
> > in your applications and add new subpages listing icons installed by
> > your application[2] (useful for theme maker people).
> > 
> > Thanks to Rodney Dawes for the original idea[3].
> > 
> > [1] http://live.gnome.org/ThemableAppIcons
> > [2] http://live.gnome.org/ThemableAppIcons/EpiphanySpecificIcons
> > [3] http://wayofthemonkey.com/index.php?date=2006-11-15&month=11&year=2006
> 
> I participated a bit in some of the xdg-list discussions about
> doing this, and I was a big proponent of having the application
> theme directory contain directories for each theme, rather than
> just have a single set of fallback icons.  For me, the big reason
> was that applications could provide accessibility versions of all
> their custom icons.

There is no reason they can't do this. In fact, this is exactly what
my recommendations here, allow you to do. You can just stick a
HighContrast or whatever other theme, alongside the hicolor theme,
in the app-private icons directory, and things will Just Work (TM),
assuming you complete the rest of the puzzle.

> What I also wanted was a standard "fallback" theme for each of
> our accessibility themes, much like hicolor is a fallback for
> other themes.  That is, our actual high contrast theme would
> continue to be HighContrast, but it would inherit from some
> other theme, like hicontrast.  That would, in turn, inherit
> from hicolor.  Applications could then install high contrast
> versions of all their custom icons in hicontrast.
> 
> Perhaps Rodney knows if there was any further discussion about
> this.  It would certainly be nice for applications to be able
> to provide for accessibility needs without being tied to one
> desktop.  And the current trend of having our accessibility
> themes try to provide everything for every application just
> doesn't scale.

I don't think there is any disagreement to wanting standard
accessibility themes across the desktops. The KDE people on the
XDG list expressed only interest in doing that, when it came up.
I don't think there has been any activity in getting it done, though.

There have also been numerous suggestions of other ways to do the
accessible themes, including automatically deriving such icons from
the selected theme's icons. Andy Fitzsimon demoed a little bit of the
work he'd been doing on this, at the GNOME Summit in October. In the
end, this may end up being the best route to take, as it could mean
that all themes are automatically accessible, and we can avoid doing
the same work over and over again in a bunch of different files in
different themes, spread across the disk, allowing us to pick up a
little performance benefit too.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: application specific themeable icons

[Rodney Dawes]

On Tue, 2007-01-16 at 13:21 +, Bill Haneman wrote:
> I have to disagree here.  While it's a nice idea with some utility, and 
> Andy is to be thanked for doing the work, it simply cannot deliver the 
> goal of readily differentiable monochrome icons across the desktop - the 
> stock graphics are just too 'busy'.  There's really no substitute for 
> purpose-built bold, monochrome icons.

This is just not true. The way the automation works, is that it doesn't
use all of the detail of the original icon. It does add a little more
work to creating the icons, but not as much as actually creating an
entirely separate theme. What you do is use certain names for elements
in the icon, and the automation code ignores other elements and only
shows the appropriate paths, for the type of a11y icon needed.

You really should look into what he's doing and how he's doing it,
before you just write it off completely.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Recolorable themes

[Rodney Dawes]

On Wed, 2007-01-17 at 13:45 +0100, Rodrigo Moya wrote:
> On Tue, 2007-01-16 at 21:44 +0100, Étienne Bersac wrote:
> > Hi,
> > 
> > > 2) Save in a custom xml format file in ~/.gnome2/color_schemes.xml 
> > > (similar to the way the gnome background manager saves the current 
> > > background settings)
> > 
> > I find this solution quite good. (Especially if that's similar to
> > background settings).
> > 
> yeah, me too, no reason to remove the feature. Let's have the HIG review
> and fix any issues we find. Can someone from usability do the UI review
> Thomas asked for?

I don't. The last thing we need is another theme format to specify
colors in. Why can't this information be stored in gtkrc files in the
current theme directory structure that GTK+ already uses?

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Remove libgnomeui where possible?

[Rodney Dawes]

On Tue, 2007-01-30 at 12:15 -0500, Dan Winship wrote:
> On Tue, 2007-01-30 at 10:16 -0500, Tristan Van Berkom wrote:
> >- Ripping out libgnomeui is probably a good idea anyway regardless 
> >  of application startup time, if only to put more distance between
> >  modern app developers and stale, old, depricated widgets/code
> 
> There is no "i" in "deprecated". (There is also
> no "I" in "team". And there is only one "I" in "solipsism". ;-)

But there are two 'I's in Wii and Mii! 

> > But heres an idea... applications launched by the panel should be
> > watched by the panel (i.e. SIGCHILD/waitpid())

And applets of course, are launched by bonobo-activation-server. So that
wouldn't really be all too helpful either.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Control Centre

[Rodney Dawes]

On Tue, 2007-02-06 at 12:52 +1100, Russell Shaw wrote:
> If profiling has to be done to make a menu faster, it is pretty obvious
> the system it is built on is stupidly inefficient and broken, especially
> if said menu is slow on a 10 year old pc.

How well does Vista or OSX 10.4 run on that same 10 year old pc?
Software changes to meet the abilities of hardware over time. If
you're trying to run new software on very old hardware, you're going
to experience slowness and other problems. It has nothing to do with
the software being stupid and inefficient. It is simply not designed
to run on said system.

Profiling should be done on any piece of software, regardless of how
fast you think it should just be. There's always room to make things
faster.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Missing mimetype icons in gnome-icon-theme

[Rodney Dawes]

On Fri, 2007-02-16 at 00:08 +0200, Naba Kumar wrote:
> Hi,
> 
> I just noticed that many text file mimetype icons found in
> gnome-icon-theme version 2.14 are missing version 2.16. For example, in
> 2.14, there are:

> Please tell me if this is just work in progress with the new icons set
> or some political agreement to remove all distinction between the file
> icons.

No. Most end users are going to almost never have to deal with source
code, or lots of various other specific types. Also given that so many
people who do write applications, create new specific types, it makes it
incredibly hard, annoying, and tiresome to draw icons for specific
types. For example, with C, C++, H, JS, and other similar types, you're
basically going to end up with the same icon used over and over again
anyway, with the only difference being an emblem of the letter "C" or
whatever, on top, or you're going to end up trying to shove too much
into the icon.

However, we do want to provide sets of specific icons external to the
default theme, for various types of users. The "artist", "developer",
"musician" and similar sets, which one can drop in to ~/.icons/ and
will Just Work to allow the users that need those icons, to have them.
But, the default look of the desktop is the most important. If we spend
all our time drawing icons for developers, we won't have the time to
spend polishing the pieces that really need it. Right now, we're doing
just that.

Vinicius Depizzol has already started on a set of icons for various
developer file types. He's drawn Python and PHP MIME type icons, derived
from the Tango Icon Theme's text sheet. The Python icon is very nice, at
least, given that Python now has a nice simple, meaningful logo. The PHP
icon on the other hand looks less interesting at the smaller sizes, as
the logo for PHP is the purple pill with the PHP letters on it.

If any specific types that you believe are needed, have sensible logos,
then they will be much easier to draw icons for, and we can get a
drop-in set of icons going for developers. The "patch" MIME type icon
should be fairly easy as well, since one can use the ViewCVS metaphor
for differences, with the red/green/yellow hilight.

-- dobey



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-icon-theme branched for 2.18

[Rodney Dawes]

gnome-icon-theme is now branched for 2.18.

Fighting the fight for better icons on the desktop,

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

evolution-webcal branched for 2.18

[Rodney Dawes]

evolution-webcal is now branched for 2.18.


-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Rodney Dawes]

On Mon, 2007-03-19 at 18:01 +, Richard Hughes wrote:
> So we have a sound server. Can this play themed sounds?

Once upon a time, I started a sound theme spec, based on the
current Icon Theme specification, and sounds implementation
in GNOME, as I have no idea how the KDE sound themes work.
When I sent this to the XDG list, it received nothing but
push back from all the KDE people on the list.

Perhaps it's time to propose such a spec again, with a little
revision, so that we can use it for both KDE and GNOME. We
can also specify some basic desktop sound events.

However, while it's great to have sounds for events in the
desktop, there are other useful configuration options as
well. I think it would be extremely useful to have an "events"
spec which would deal with the events portion, and a sound
theme spec to only deal with the sounds portion. The events
spec could define basic desktop events, and what potential
actions could be taken, such as play a sound, show a notification
bubble, or run a program.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Branching gnome-icon-theme for gnome-2-20

[Rodney Dawes]

As the subject states, gnome-icon-theme has been branched for 2.20 with
the gnome-2-20 branch name.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Branching ghex for gnome-2-20

[Rodney Dawes]

The ghex module is now branched for gnome-2-20.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Branching gnome-icon-theme for gnome-2-22

[Rodney Dawes]

As the subject states, gnome-icon-theme has been branched for 2.22 with
the gnome-2-22 branch name.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Move intltool to External Deps from Dev Platform

[Rodney Dawes]

Hi,

I would like to propose that we remove intltool from the Developer
Platform module set, and place it in External Dependencies. As
intltool is a build tool, rather than a library, and is meant to
be useful outside the scope of GNOME. The project web page and
mailing list are hosted on FreeDesktop, though the mailing list is
basically a spam dump at this point.

As intltool is a generic build tool, it is meant to be used by more
projects than just GNOME, and I would like to start furthering that
ideology. There is currently interest in possibly using intltool for
translatable resources in WINE as well. I think it makes more sense
as an external dep, than as part of the platform modules.

What do you think?

Thanks,
Rodney


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: intltool move

[Rodney Dawes]

On Fri, 2009-04-24 at 03:59 +0200, Vincent Untz wrote:
> Le dimanche 19 avril 2009, à 15:25 -0400, Rodney Dawes a écrit :
> > The intltool product on bugzilla.gnome.org is now closed for new
> > reports, and the SVN module was moved over to svn-archive before the
> > gnome.org transition to git. The latest intltool code is already in a
> > bzr branch on Launchpad (lp:intltool) and, all new bugs should be
> > reported at http://bugs.launchpad.net/intltool/ from now on. There are
> > still a few open bugs in bugzilla, which Danilo or myself will deal
> > with as appropriate, by fixing, moving, or closing as wontfix.
> 
> Going to https://bugs.launchpad.net/intltool/+filebug, I get:
> 
> "intltool does not use Launchpad as its bug tracker."

Doh. Sorry about that. Should be fixed now.

Thanks.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GtkHTML 2 Development

[Rodney Dawes]

What is up with gtkhtml2? It seems to not have had any releases since
the last one of 2.6.2, and yelp seems to have suddenly dropped it
completely in 2.9, in favor of gecko that opens a whole slew of a11y
regression problems, and I've seen no announcements of removing it
from the desktop or platform (if it's in the platform libs), or even
yelp. I discovered yelp didn't use it any more when trying to upgrade
to 2.9.

It seems like yelp should use gtkhtml2 by default, for the a11y issues,
and make gecko optional, until it's sufficiently accessible.

Anyway, is gtkhtml2 just completely unmaintained now? If so, I'd like to
grab maintainership of it, and do some work with it.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GtkHTML 2 Development

[Rodney Dawes]

Thanks. I'll take that claim then. :)

-- dobey

On Fri, 2005-02-04 at 18:15 +, Padraig O'Briain wrote:
> Rodney,
> 
> I am nominally the maintainer of gtkhtml2. You are welcome to take over 
> maintainership of it.
> 
> Padraig
> 
> Rodney Dawes wrote:
> 
> >What is up with gtkhtml2? It seems to not have had any releases since
> >the last one of 2.6.2, and yelp seems to have suddenly dropped it
> >completely in 2.9, in favor of gecko that opens a whole slew of a11y
> >regression problems, and I've seen no announcements of removing it
> >from the desktop or platform (if it's in the platform libs), or even
> >yelp. I discovered yelp didn't use it any more when trying to upgrade
> >to 2.9.
> >
> >It seems like yelp should use gtkhtml2 by default, for the a11y issues,
> >and make gecko optional, until it's sufficiently accessible.
> >
> >Anyway, is gtkhtml2 just completely unmaintained now? If so, I'd like to
> >grab maintainership of it, and do some work with it.
> >
> >-- dobey
> >

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: .desktop file handling

[Rodney Dawes]

On Sun, 2005-02-06 at 19:05 +0100, Marco Pesenti Gritti wrote:
> Hi,
> 
> I think libgnome-desktop is not supposed to be public API. From the README:
> 
> "The package contains the libgnome-desktop library
> which contains APIs that really belong in libgnome[ui] but
> have not seen enough testing or development to be considered
> stable. Use at your own risk."

Odd. Didn't this API used to be IN libgnome[ui]? I certainly remember it
being in gnome-core in Gnome 1.4.

> > Also if you want to launch an application using the startup-notification
> > stuff, you need to use libgnome-panel (although I have raised bug 166197
> > about gnome-vfs not using startup-notification).
> 
> In both cases the problem is that gnome-vfs cannot depend on gtk.
> There are vague plans of a libgnomevfsui library for other things...
> that could be a good place to put launch with notification/icon apis
> too.
> 
> Out of curiosity can you explain the use case of the icon api?

I think the problem is that the Icon Theme API that doesn't actually
depend on X at all, is in GTK+, rather than glib. And, in the grand
scheme of things, gnome-vfs already depends on GTK+ indirectly anyway.
It depends on GConf, which needs GTK+ for the error dialog dingus.
Neither of the libraries directly depend on it though. Also, much of
the Icon Theme API seems like it would be useful outside of icon themes
as well. And it might be nice to reduce all the desktop/theme/whatever
INI-style parsing code to one single API sometime too, rather than
having a bunch of different INI parsers all over the place.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1

[Rodney Dawes]

Run "gnome-control-center". The current tarball release is kind of lack
on the categories though, due to the new menus from Ubuntu or whatever,
since everything is all in the same toplevel, except for a11y stuff.

-- dobey

On Mon, 2005-02-07 at 13:07 -0400, Steven Garrity wrote:
> Jody Goldberg wrote:
>   > 2.10 will include an updated variant of the old ximian OSX style
> > flat layout.  It does look ideal with the default arrangement of
> > .desktop files.   Jeff, Chrisian raises some reasonable points with
> > his tab based design.  The OSX style layout flounders badly when the
> > number of capplets grows larger than about 4 x 5.  Enforcing that
> > limit requires a white-list or you end up with windows style random
> > capplet additions with every new application.  A promising solution
> > for the remainder is an 'Other' tab.
> 
> Can you clarify what is meant my the "old ximian OSX style flat layout"?
> 
> Thanks,
> Steven Garrity


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1

[Rodney Dawes]

Agreed.

-- dobey

On Mon, 2005-02-07 at 13:22 -0500, Havoc Pennington wrote:
> On Mon, 2005-02-07 at 18:22 +0100, Christian Neumair wrote:
> > As Jody pointed out, the Apple layout doesn't work very well for many
> > items - and we HAVE many items. While about 20 in the default setup are
> > still OK, we have to deal with the fact that new items will be added. So
> > the Apple approach seems to be badly scalable.
> 
> Planning to be "scalable" here is exactly the wrong thing to do. The
> person using the UI is not scalable. We should just assume there is a
> hardcoded limit of 15-20 items; and fix any and all reasons there are
> more.
> 
> If apps are installing extra items, then we should either remove the
> capability, or shove these extra items in some secondary location (like
> "other" or an "application items" tab or something) and say "if your
> control panel sucks because apps install crap, then it's the apps fault,
> file an app bug" - maybe we could put in the HIG:
> 
>  "The control-center is for desktop settings, i.e. stuff that does not
> appear to users to be
>   associated with any particular application. Do not put your app
> preferences there."
> 
> The Applications menu is the same way. Once you exceed a certain number
> of items, it's just not possible to arrange them sanely.
> 
> I like the part of this page
> http://www.joelonsoftware.com/uibook/chapters/fog63.html
> starting with  "Here's a common programmer thought pattern: there are
> only three numbers: 0, 1, and n."
> 
> The UI should be designed for a number of apps/control-panels people
> will use, not for N items. Then we should be sure we focus the defaults
> of GNOME (and each OS that includes GNOME) around a specific enough
> target audience that we can keep the number of items low. Failing that,
> we should make it easy for site admins to focus their local defaults
> using their knowledge of their users.
> 
> There are tons of ways to limit the number of items if we aren't lazy,
> even ignoring the option to just remove silliness. Prefs don't have to
> be in the control panel. They can be made available in the contexts
> where you will use them - e.g. media prefs in the media player, file-
> related prefs in the file manager, prefs that appear when you take an
> action like plug in a device, etc.
> 
> Personally I think some time thinking through which prefs exist, and
> whether they can be moved outside the control center, would be a lot
> more valuable than continuing to try and bandaid the "too many prefs"
> problem with new control center shells.
> 
> Havoc
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1

[Rodney Dawes]

This is what we currently have in 2.10, for the most part.

-- dobey

On Mon, 2005-02-07 at 22:40 +0100, Danilo Åegan wrote:
> Today at 22:17, Danilo Åegan wrote:
> 
> > I should perhaps create a mock-up to illustrate what I mean :)
> 
> Here you go:
> 
>   http://kvota.net/~danilo/gcc-mockup.png
> 
> So, if we design well, we won't have more than one line of icons per
> category.  "Other" category might end up with several rows, but that's
> not our responsibility. 
> 
> Don't laugh at my artistic skills, though :)
> 
> Cheers,
> Danilo


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1

[Rodney Dawes]

This is a bug, that I believe jody just fixed in HEAD. Given proper
categories, you get the same UI that you were talking about, and that
Mac OS X uses.

-- dobey

On Mon, 2005-02-07 at 23:18 +0100, Danilo Åegan wrote:
> Today at 22:57, Rodney Dawes wrote:
> 
> > This is what we currently have in 2.10, for the most part.
> 
> How come?  "gnome-control-center --use-shell" (2.9.4) gives one
> big load of icons, and we have an uncategorised menu on the panel. 
> 
> Did I miss anything (I think gnome-vfs URI was abandoned)?
> 
> Cheers,
> Danilo
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Exciting GNOME?

[Rodney Dawes]

On Mon, 2005-02-14 at 19:36 +0100, Maciej Katafiasz wrote:
> Anything besides obvious "it needs to be distributed separately" thing?
> Does the fact that engines are compiled binaries ever cause compat
> problems?

There are always going to be compat issues, binary or not. You either
have a binary API or a string API, or some other API, that will require
compatibility on some level.

> On a related note, there was one (vague, but nevertheless very
> desirable) point on GTK+ 2.8 TODO list: "now we have cairo and all the
> goodness, make theme engine that would be far more flexible and allow us
> to specify declaratively what's currently being done via engines, fix
> all the currect shortcomings of theming and then get rid of all other
> engines". Is that still on radar, or got slipped into some unspecified
> future?

I personally don't care if metacity gets engines or not. It seems to do
well enough without them for now. However, I am very against removing
them from GTK+. There's nothing special that cairo gives us, that would
make removing the ability to have engines, any more possible than it is
now. In fact, I would prefer that they get extended, so that new widgets
can specify custom drawing routines. Sometimes, you need to completely
change the math/layout of a widget to get real themability.
Unfortunately, we don't have that.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Exciting GNOME?

[Rodney Dawes]

This isn't the place to start a KDE/GNOME flamewar. End users is very
general. Everyone likes something different. The current desktop
trendiness is to be flashy with colors and stuff. OS X doesn't really
have that much color. It's just a very well done interface. Making
things shiny with a billion colors doesn't mean it is better.

-- dobey

On Tue, 2005-02-15 at 18:46 -0200, Everaldo Canuto wrote:
> Hi,
> 
> Ok... the icons are not ugly but need more colors, I say one more time,
> the end users like colors and because this some users like Kde Icons.
> 
> End users dont like gray desktop and for a moment (except for Fedora
> users) the "G" of GNOME is a "G"ray.
> 
> Everaldo.
> 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Intltool and disting of .gmo files

[Rodney Dawes]

Currently, intltool is distributing the generated .gmo files, within
tarballs. Christian Persch recently filed a bug against intltool, as
this still causes some issues with builddir != srcdir. I'd prefer to
not duplicate generated files if possible. If anyone has sufficient
reason as to why they should be distributed, please speak up now, or
I'm going to fix intltool to stop distributing them tonight, and make
a release with some other fixes as well. The bug in question is:

http://bugzilla.gnome.org/show_bug.cgi?id=166724

Thanks.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Default Theme Progress

[Rodney Dawes]

On Mon, 2005-02-28 at 18:27 -0400, Steven Garrity wrote: 
> Hey Novell people: what about you guys? Any interest in Clearlooks?

I've none really. It looks like Bluecurve. Whoo. There's nothing
particularly special about it. Same stuff, different colors. It's
not as ugly as "Simple" was, but few things are really. Maybe Crux
and Mardi Gras or whatever it was. And, looking back at the Wiki
page (which btw, wikis suck for discussion, as there's no push
method, and it's all manual polling, so i hate that this has
been going on, on a wiki anyway), I don't see any particular
consensus to use a certain theme. It seems more like Seth just
went about and decided today that ClearLooks would be the new
theme. I thought there was supposed to be some design put into
creating a new theme for 2.12? What happened to that contest
that everyone was talking about? The wiki page is totally incomplete
for deciding on a new theme. 

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Default Theme Progress

[Rodney Dawes]

On Tue, 2005-03-01 at 00:59 -0500, Seth Nickell wrote:
> On Tue, 1 Mar 2005 14:15:45 +1100, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > > At that point, Seth's email was *crystal clear* that this WILL be the
> > > default theme of Gnome 2.12.
> > 
> > Seth confirmed that we were TALKING about the default theme for 2.12, not
> > that we had DECIDED on the default theme for 2.12. The only crystal clear
> > point made in Seth and Diana's mail is that Clearlooks is in the lead for
> > the moment, and we should at the very least ship it.
> 
> Jeff is right, we have not firmly settled on the default theme for
> 2.12. For example, I would like to get Clearlooks in CVS and get
> people using it with lots of different apps to verify that its robust,
> doesn't leak memory, works with all apps, etc before we switch the
> default. Another thing we have to look at is colours, which we haven't
> even started delving into wrt to Clearlooks.

Are we going to do the same for all the other proposed themes? It seems
to me that if we just shove ClearLooks in and expect people to test it,
that it will trap to being the default, by virtue of the fact that it
simply at least looks better than Simple for most people. If the goal
of the mail Diana sent was to announce that it would be going in to
CVS for testing purposes, and is still only proposed, I see no reason
we shouldn't do likewise for the other proposed themes.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Intltool and disting of .gmo files

[Rodney Dawes]

On Tue, 2005-03-01 at 11:02 +0800, James Henstridge wrote:
> Rodney Dawes wrote:
> 
> >Currently, intltool is distributing the generated .gmo files, within
> >tarballs. Christian Persch recently filed a bug against intltool, as
> >this still causes some issues with builddir != srcdir. I'd prefer to
> >not duplicate generated files if possible. If anyone has sufficient
> >reason as to why they should be distributed, please speak up now, or
> >I'm going to fix intltool to stop distributing them tonight, and make
> >a release with some other fixes as well. The bug in question is:
> >
> >http://bugzilla.gnome.org/show_bug.cgi?id=166724
> >  
> >
> I think the reason why gettext's Makefile.in.in distributes the .gmo 
> files is so that you can install the translations from a tarball install 
> even if you don't have the gettext utilities installed (msgfmt, etc).

Perhaps. I think it's safe to assume that if one doesn't have gettext
installed though, they probably don't want translations anyway, if they
are building from source. Translators should really have the gettext
tools installed anyway, so that they can test their changes.

> I haven't noticed any builddir!=srcdir problems with the stock gettext 
> or glib-gettextize Makefile.in.in, so I guess this is an intltool 
> specific problem.  Is there any reason not to follow what the existing 
> tools do here?

I'm surprised glib-gettextize's Makefile.in.in would work. Intltool's
Makefile.in.in is almost exactly the same as glib's, with appropriate
changes to use intltool's maintanence utilities and the like. Though, it
does look like the glib-gettextize Makefile.in.in likes to generate the
gmo files and pot file in srcdir instead of builddir. That seems more
broken to me.

Anyway, favortism seems to support not disting the gmo files, as it
saves quite a bit of size in the tarball, so I'm going to commit the
change.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-icon-theme has been branched

[Rodney Dawes]

I just branched gnome-icon-theme for gnome 2.10. The branchpoint is
based off the last 2.10 release.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

evolution-webcal has been branched

[Rodney Dawes]

I just branched evolution-webcal for gnome 2.10. HEAD will soon be
versioned as 2.3.0 and will check for libsoup 2.4 and fall back to
2.2 if 2.4 is not found.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Control center and capplet merging

[Rodney Dawes]

Merging items could be useful. However, I don't think just shoving the
same existing UI into multiple tabs in a single dialog will help really.
It will just mean less things in the menu, and more confusion to users
who are looking for things that are no longer there.

See gnome-control-center. This is in gnome upstream now. However, it is
totally hidden. :-/

-- dobey

On Mon, 2005-06-27 at 09:14 -0400, Eric Larson wrote:
> On the usability front, I am not sure it is best to merge tools. While
> it does make some sense it could also be more confusing to the user
> because it forces the user to deal with fonts when they only want to
> change the theme. I think the larger issue is not how many system/admin
> tools there are but rather how they are organized. This is a subtle
> difference but I think it makes some sense. BTW, I am using debian
> unstable if anyone would like to know what I am seeing. 
> 
> The Desktop menu on the panel has a huge amount of options which are
> organized into one long list. It seems things could be better by having
> an actual control panel that could help to organize different areas
> better. Something in nautilus where the view shows a title and break
> before showing icons specific to that group could be helpful in
> organizing the mass of preferences while keeping each individual
> interface clean and simple. Although, I am a bit bias, Ximian desktop
> does this. It needs work of course because it is pretty out of date, but
> if we consider things like windows users and mac users, a control panel
> type window that shows preferences in an organized fashion may be very
> usable. 
> 
> This is Just my two cents of course :) I am not sure of the current
> scope or context of this problme so I apologize in advanced if it is not
> relevant. 
> 
> Eric


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Default theme

[Rodney Dawes]

Let's just remove everything else, and put Clearlooks in, and move the
a11y themes to their own tarball. :)

-- dobey


On Fri, 2005-07-15 at 17:41 +0100, Calum Benson wrote: 
> On Thu, 2005-07-14 at 17:17 -0500, Shaun McCance wrote:
> 
> > The tarball also contains Clearlooks.diff.  Apply this patch to
> > get all the build files right.  Build, install, witness the glory.
> 
> I don't mind adding it to gnome-themes, but I think I'd be wanting to
> take something else out to make room for it at this stage, and that's
> where the arguments start :)  (Of course, just adding it to gnome-themes
> doesn't make it the default, either...)
> 
> Cheeri,
> Calum.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clearlooks and GNOME 2.12

[Rodney Dawes]

On Tue, 2005-07-19 at 23:26 +0200, Danilo Šegan wrote:
> Today at 22:42, Richard Stellingwerff wrote:
> 
> > Personally, I'd really prefer to keep distributing standalone
> > packages, since it allows me to do more frequent releases. 
> 
> Nobody would object if gtk-engines got more frequent releases. :)
> 
> I.e. this should not impact a decision, since if clearlooks is
> included and maintained inside gtk-engines, you could ask for releases
> as often as you wish, or even more likely, do them yourself. 
> 
> I can't imagine anyone complaining about someone else doing the work :)

I'd personally prefer that the engines were separate. It means that you
avoid having to apply the same version number to a lot of different
engines, even those that may be substantially less stable than others.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Maintainership of gnome-common

[Rodney Dawes]

So,

The maintanence of gnome-common has been on the lax as of late. James
seems to be too busy or something, and I don't know what has happened to
Malcolm. He seems to just not reply at all to some bug reports.

However, there are some patches in bugzilla that need more
review/approval. I've given feedback on several bug reports.

A new release has also been requested on d-d-l within the past few
weeks, and it was stated that one would be made, but still no release
has happened yet.

Given these facts, and my inane ability to overextend myself and do evil
things with build systems, I would like to suggest that gnome-common
maintainership be moved to me. Or at least someone with the time to
read their bug mail, and go approve a patch, and make a release every
now and again.

If nobody complains in the next few days, I'm just going to take it
over, commit a patch or three, and make a release.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cleaning up themes

[Rodney Dawes]

On Sat, 2005-07-30 at 12:18 -0400, Owen Taylor wrote: 
> On Sat, 2005-07-30 at 16:58 +0200, uws wrote:
> > På Sat, Jul 30, 2005 at 02:52:30PM +0200, Murray Cumming skrev:
> > > On Sat, 2005-07-30 at 12:18 +0800, Davyd Madeley wrote:
> > > > I'm sure I've brought this up before, but I think we should clean up the
> > > > list of themes we ship for G2.12.
> > 
> > > Maybe for 2.14/2.14, but I'm not personally going to approve this
> > > feature-freeze break. It's bad enough that the change of the default
> > > theme has taken this long. Well, maybe it'd be ok to remove the non-
> > > default "default".
> > 
> > If the default is just the built-in theme in GTK+ (no way to check now, no X
> > over here), I think a rename to "Built-in" is the best.
> 
> The Red Hat packages have renamed this theme to "Raleigh" for a long
> time to avoid having a non-default Default. (It is derived from the
> Raleigh theme we did for GTK+-1.2)

Can we get this done upstream also? Or perhaps with some other name, if
Raleigh is not suitable?

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cleaning up themes

[Rodney Dawes]

On Sat, 2005-07-30 at 09:54 +0100, Thomas Wood wrote: 
> 
> It is already possibly to install themes straight from art.gnome.org by 
> dragging and dropping the links into gnome-theme-manager. What would be 
> ideal would be a new mime-type for gnome themes, and a proper file 
> format for themes too. Then we could do the install (and possibly 
> apply) straight form clicking on a link. I made several suggestions on 
> a file format and mime-type for gnome themes a while ago, but it didn't 
> get much further than a few ideas on paper.

Let's not bring this up in this thread again. We can whitewash that
bikeshed later, perhaps on gnome-themes-list or something. Basically,
it doesn't really make sense to do this, as long as we are going to need
architecture-dependent data for themes.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cleaning up themes

[Rodney Dawes]

On Sat, 2005-07-30 at 21:52 +0100, Thomas Wood wrote: 
> Packaging engines has been one of the sticking points for distributing 
> GTK+ themes. However, a simple check for the existence of a library 
> could notify the user if a theme being installed will not work because a 
> theme engine is not present. While not ideal, we certainly don't want to 
> start trying to distribute binaries. However, a proper packaging system 
> needs to be designed in order to accommodate this.

Proper packaging systems have been designed to accomodate this. It just
happens that everyone uses their favorite one, in their own special
ways. Yet another packaging format to deal with on a single distribution
is even further from an ideal situation, I think. If anything, it is
probably better to work toward getting rid of the need for binary
engines, to change more fundamental properties of widgets.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: change an environment variable in a running gnome session

[Rodney Dawes]

On Fri, 2005-07-29 at 11:29 -0500, Federico Mena Quintero wrote:
> Long answer: what exactly are you trying to do?  There may be a way
> within GNOME to do it.

If it's to change the locale settings without logging out of gnome, and
back in, then I have some ideas on how to make that work, that I will be
playing with soon. If everything works as I think it will, then we can
probably get this into gnome 2.14. :)

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cleaning up themes

[Rodney Dawes]

On Sat, 2005-07-30 at 23:54 +0100, Mike Hearn wrote:
> On Sat, 2005-07-30 at 21:52 +0100, Thomas Wood wrote:
> > The top 5 rated GTK+ themes on art.gnome.org actually use engines that 
> > should already be available in most distributions, since they are 
> > included in gtk-engines, or use the pixmap engine which is now available 
> > in GTK+. 
> 
> ClearLooks is still pretty new - I don't think it's available in Fedora
> Core <4, right? Lots of users haven't upgraded yet.
> 
> Anyway, I'm sure your right and most engines are now in gtk-engines, you
> guys do a great job of maintaining that and keeping it responsive.
> Still, especially once Cairo/GTK+ 2.8 is out and drawing isn't only for
> people who enjoy pain anymore I'd expect to see lots more theme engines

Cairo doesn't really make writing a theme engine easier. It mostly just
makes alpha curves easier, and adds alpha blending to straight lines as
well. If it were really to make themeing easier, I would expect to see
less engines, and more themes that do not require engines. But I do not
know if any changes have been maded to the default style to make buttons
round, or less 3d, with the default look.

> > However, a simple check for the existence of a library 
> > could notify the user if a theme being installed will not work because a 
> > theme engine is not present. 
> 
> That's incredibly lame, it'd be better not to give one-click installs at
> all if it'll randomly fail on the hottest new themes.

It won't randomly fail, it would warn the user I hope.

> > While not ideal, we certainly don't want to start trying to distribute 
> > binaries. 
> 
> Why not? ;)

Because there is no standardized packaging format and distribution
method, and beyond that, the distributions that do use the same package
formats, often have different policies for where things actually go on
the filesystem? And no, autopackage is not a solution for it. Most
people do not have it. Adding yet more places for a user to have to
look to see what versions of software they have, what upgrades are
available (which will cause a LOT of problems, as software will be in
one database, but not the system packaging db), and other such
utilities, will just add confusion to the process.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cleaning up themes

[Rodney Dawes]

On Sun, 2005-07-31 at 00:36 +0100, Mike Hearn wrote:
> >> That's incredibly lame, it'd be better not to give one-click installs at
> >> all if it'll randomly fail on the hottest new themes.
> > 
> > It won't randomly fail, it would warn the user I hope.
> 
> I meant it'd randomly fail from the users perspective, because there's no
> way to tell ahead of time if a new engine is used or not.

The entire point of Thomas's proposal is to tell ahead of time if a new
engine is needed or not. It is a minor implementation detail to read a
small file off the server, and check for the engine.

> > Because there is no standardized packaging format and distribution
> > method
> 
> Theme engines are usually just DSOs right? Or at least, if they
> include extra data that can be compiled in to make it a single DSO. That's
> one file, which can be installed to a known place that can be determined
> easily at runtime (at least on Linux). So it would definitely be possible.

So I should be able to take any single binary DSO object, and shove it
on any other random linux install on any random hardware, and it should
work? Anything is technically possible here. Nobody is questioning
possibilities. What is being questioned, is correctness, and making the
whole general bit of random stuff of the internet that comprises the
realm of Open Source/Free Software, into something that a user can
easily deal with and enjoy. If we do make it possible to install the
engines themselves, I can tell you right now that art.gnome.org is not
going to be the only place providing them. And given the huge dive in
control of such a format, it is not particularly reasonable to assume
that it will Just Work (TM).

> > and beyond that, the distributions that do use the same package
> > formats, often have different policies for where things actually go on
> > the filesystem?
> 
> Themes are always installed to the same place relative to GTK+ itself
> though.

But you are not sure where GTK+ might be. If you are unsure where GTK+
is, and of the environment in which you are installing things, how can
you reasonably guarantee that it will work.

> > And no, autopackage is not a solution for it. Most people do not have it.
> 
> It installs itself the first time you use it (by running the package).

> > Adding yet more places for a user to have to look
> > to see what versions of software they have, what upgrades are available
> > (which will cause a LOT of problems, as software will be in one
> > database, but not the system packaging db), and other such utilities,
> > will just add confusion to the process.
> 
> There's no fundamental reason why autopackages (or .themes or whatever)
> can't update themselves automatically and use the system database instead
> of a separate one, it just hasn't been done yet.

Then there's no fundamental reason why we can't just provide packages
that are actually intended for the system they are being installed on.

> And how important is it that themes are upgraded automatically anyway?
> They aren't security-critical. Is it really more important than easy
> one-click installs of new eyecandy (which is a nice end user feature)?

I said nothing about updating automatically. I was talking about where a
user would go to find updates. If it happened automatically. Easy
one-click installs of new eyecandy really isn't that important anyway.
Most distributions ship most theme engines anyway, and a lot of extra
themes. I think it's more important to get a nice "theme editor" UI
in the control center, for users to set the appearance of their desktop.
One-click installs would be nice, sure, and I would support doing it, in
the right way, that will work for everyone on all architectures. Another
thing to remember, is that not all Gnome users are Linux users. Solaris,
BSD, and other systems have plenty of users are Gnome users, too.

Can we also please stop painting this shed in a thread about
gnome-themes maintanence now? It's not really appropriate. If you want
to continue the discussion of themes distribution, feel free to move it
over to gnome-themes list. Thanks.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-about-me

[Rodney Dawes]

On Tue, 2005-08-02 at 11:07 +0200, Chipzz wrote:
> I think (but my guess is as good as any) that the intention here is to
> have evolution use the information you provide here.
> Gaim doesn't use gconf, so that's a different story altogether

I think it can optionally use it now. That is, I believe a patch to
conditionally enable it, was accepted recently.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: audioconvert! the new super script to convert audio files! would you like to include it?

[Rodney Dawes]

On Fri, 2005-08-05 at 02:06 +0200, Samuel Abels wrote: 
> Am Freitag, den 05.08.2005, 04:17 +0200 schrieb edoardo:
> > recently i made a nautilus script that allows you to convert audio files 
> > by right-clickin' on'em from nautilus.
> > 
> > i was wonderin' if you guys might have wanted to include it in the next 
> > official gnome release.
> 
> Though the script is probably useful for many people I believe that in
> GNOME we have a general consensus that technical details should not be
> exposed to the user, whenever possible. That also includes file formats
> such as OGG, FLAC or mp3. If a requirement to convert a format does come
> up (e.g. through hardware player constraints) the applications that
> interface with this hardware should be fixed to automatically convert
> the format accordingly, so that the user is not confronted with the
> format at all.
> Thus, I believe your script is a great enhancement, but it should not be
> included in the GNOME default release for the above reasons.

I would generally agree about the technical details argument. However,
there is no single piece of hardware that plays all arbitrary audio
formats at this time, in terms of portable audio players. MP3 is very
widely known now, for example, and pretty much all portable digital
audio players do support it. Very few support OGG/Vorbis, and even
less support FLAC.

Having said that, I've not yet seen the original e-mail, and have not
googled to find the software in question, so have yet to try it.
However, I still am not sure that nautilus scripts is the best UI for
doing something which may be so important to the user. Converting the
audio when the user chooses to sync it to their hardware device, in
the music library application, is definitely not the way to do it
though. I have a 60GB iPod, and would certainly not want to wait for
the amount of time it would take to convert 60GB of my OGG files, to
MP3. I also would not want the software to assume that the iPod does
not support OGG, either. It may not do so officially, but I do intend
to install iPodLinux on it, so that I can just use OGGs directly.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Trademarked icon in gnome-icon-theme

[Rodney Dawes]

It looks like Jakub has already removed this.

On the note of trademarks however, Is there really any reason that
evince needs to embed the Adobe Acrobat logo in the thumbnails it
creates? see: http://www.gnome.org/~dobey/evincethumb.png

I'm also going to go ahead and remove all the icons from g-i-t that
include trademarked images. I knew this was going to come up sooner
or later when I took over maintainership, but was hoping it could
last until we can get the new icon naming spec stuff and a generic
type fallback mechanism working, before it had to be done.

-- dobey

On Sun, 2005-08-07 at 21:22 -0700, Jeff Waugh wrote:
> I've filed a bug , but
> this seemed important enough to raise here for exposure before we release (I
> didn't want to mark it as a blocker).
> 
> gnome-icon-theme ships the mozilla.org trademarked firefox logo. Not only do
> we not have the right to ship this under their licensing requirements, but
> it would impact on our distributors too.
> 
> Thanks,
> 
> - Jeff
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcing: Project Ridley

[Rodney Dawes]

If someone wanted to port fontconfig to support libxml2, I'm sure the
patch would get accepted, were it reasonable. The code actually used to
have a configure option to use libxml2 instead, but it was not getting
the maintanence it needed, so it was removed.

Beyond that, the only other thing which I care about that uses expat,
is the XML::Parser perl module, which we require for intltool.

Most everything else in terms of Gnome, use libxml2 anyway. Gnumeric,
Abiword, the background capplet, gconf, etc... all use libxml2.

-- dobey


On Tue, 2005-08-23 at 22:06 +0200, Emmanuele Bassi wrote:
> Hi all,
> 
> On Tue, 2005-08-23 at 13:25 +0100, Alberto Manuel Brandão Simões wrote:
> > I am entering into the discussion thread without reading any other email 
> > than this one, but... as for XML we should not create the wheel again.
> > 
> > That leads to libxml2 or expat. In my case, I prefer libxml2. Being part 
> >   of w3c development maybe helps me choosing it. Well, having work with 
> > expat a long time ago when it was slower than libxml2 might help my 
> > decision as well.
> 
> Gtk already depends, albeit inderectely, on expat by depending on
> fontconfig.
> 
> Anyway, I'd like a dependency on libxml2, since my RecentManager code
> uses it for the storage file.
> 
> Just my .02€
> 
> Ciao,
>  Emmanuele.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcing: Project Ridley

[Rodney Dawes]

Not for me. The installed package on my machine requires libxml2, but
does not have a dependency on libexpat. However, the dbus-gtk stuff
seems to, though presumably that is indirect due to pango's dependency
on expat, which gtk+ requires for obvious reasons.

-- dobey

On Thu, 2005-08-25 at 19:32 +0300, Olexiy Avramchenko wrote:
> dbus also depends on expat.
> 
>   Olexiy
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcing: Project Ridley

[Rodney Dawes]

On Thu, 2005-08-25 at 13:33 -0400, Behdad Esfahbod wrote:
> On Thu, 25 Aug 2005, Rodney Dawes wrote:
> 
> > Not for me. The installed package on my machine requires libxml2, but
> > does not have a dependency on libexpat. However, the dbus-gtk stuff
> > seems to, though presumably that is indirect due to pango's dependency
> > on expat, which gtk+ requires for obvious reasons.
> 
> Excuse me?!  grep -r expat pango/ doesn't suggest anything.

Jesus. Doesn't anyone read the entire thread. Pango depends on expat
indirectly through fontconfig. Sheesh.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gtkspell (was Re: Announcing: Project Ridley)

[Rodney Dawes]

On Sun, 2005-08-28 at 13:33 +0200, Martin Soto wrote:
> I think that having to write in at least two languages on a regular
> basis is a common situation for many users, that should be taken into
> account not only by libraries like gtkspell but by applications. For
> example, I'd really love having a combo box in Evolution composer to
> switch languages quickly (the current menu is awkward because you have
> to open it twice: once to deactivate the current language and once to
> activate the new one). Automatic selection of the language based on the
> recipients list would be even better.
> 
> Also, being able to separately set the language for Tomboy notes would
> be really great, making a nice application even nicer.

I would rather just see it work for all installed language dictionaries
by default. There's no particular reason to make the user change their
language in so many ways. For most users, I think this will work best.
There might be some performance problems for people who install an
extraneous amount of languages, but I don't think most people do that,
and the performance issues probably wouldn't be that big of a deal
anyway.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Version numbers of apps in the gnome desktop.

[Rodney Dawes]

What happens if the version number is already greater than that of
Gnome?

-- dobey


On Sat, 2005-09-10 at 23:11 +0200, Jaap Haitsma wrote:
> Out of curiosity. Why would it be a problem to make it a requirement to 
> bump the version number?
> 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cdda://, ftp://, news:// URIs and the default handler

[Rodney Dawes]

Perhaps it is time to get a cross-desktop url-handler implementation
specified on freedesktop.org and implemented so we can use that instead.
We would want Konqueror, Firefox, Gaim, and whatever else to all open
the same handler for a given URI, for example. Though, personally I
would prefer that it passed off the url to the proper MIME handler, if
it can open from URIs, and fall back to the specified http, or whatever
handler if it can't.

-- dobey


On Wed, 2005-09-21 at 12:19 +0200, Stanislav Brabec wrote:
> Federico Mena Quintero wrote:
> 
> > We don't install a default handler for "cdda" URIs (in
> > gconf's /desktop/gnome/url-handlers/cdda/*).  That's not fine, and it's
> > the cause of this bug.
> 
> I got few bugs for SuSE Linux - clicking to news:// in firefox, ftp://
> in evolution.
> 
> All these bugs were simply fixed by adding proper
> desktop/gnome/url-handlers keys. IMHO we should enhance list of URIs
> known by core GNOME (and change control-center to allow to set them).
> 
> I can open a bugzilla item about it. I have created a script, which
> updates all translations, too.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Totem to play audio files

[Rodney Dawes]

On Sat, 2005-10-08 at 15:21 +0200, Frank Niedermann wrote:
> If Rhythmbox may be too complex as default audio player in Gnome what
> about a compromise like Eina:
> http://bolgo.cent.uji.es/proyectos/eina#shots

I just tried to use this. The latest version doesn't seem to build
against dbus 0.50, though it does require dbus. I tried an earlier
version that didn't require dbus, but it didn't build with the
latest version of libeina, and I had to downgrade that as well.
It also seems as if it is unmaintained, as the last commit was in
January, and the svn seems to no longer exist for it.

Unfortunate really, because I like the screenshots, so I'd like to
try it. The version I did get built, doesn't seem to find the
gnomevfs plug-in in gstreamer, and then eats up most all the CPU
when I try to add a file to the playlist.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: control-center - some input for Common Plan

[Rodney Dawes]

On Mon, 2005-10-17 at 12:29 +0100, John Rice wrote:
> Cool,
> 
> I've been thinking about this after the summit and scratching heads with 
> Darren Kenny and Calum Benson about the Control Center [my own head I 
> hasten to add, not Darren's or Calum's ;) ].
> 
> Few thoughts to put into the pot when you are considering your common 
> plan on this:
> 
> 1. Categorization: Preferences revisited has already done some work on 
> trying to consolidate and categorize things more sensibly than they have 
> been: http://live.gnome.org/PreferencesRevisited
> 
> We took at look at these suggestions, looked at Max OSX, MS Vista, NLD 
> and Fedora Core [menu layout equiv] and have just rolled a spreadsheet 
> that try's to capture what I think is a reasonable first stab at a 
> sensible categorization [attached in Calc format]. Will post it up to 
> http://live.gnome.org/PreferencesRevisited as well.

I've looked a little bit at this, but not had time to do a full review
and post my thoughts. I'll try to get to doing that soon though.

> 2. Control Center Applet UI: Would be great once we have broad agreement 
> on Categories to come up with a consistent UI to present this info to 
> the user. So going to set one thing doesn't look dramatically different 
> to any other Control Center applet. Should be possible for property 
> based stuff as least, going into Screen layout stuff gets a lot more 
> challenging, but little steps ...

Presenting some pieces of data is going to be vastly different than
presenting other pieces of data. For example, I imagine that
presentation of settings for hardware is going to be quite different
than presentation of choice for appearance related settings. This will
largely be solved by the consolidation of capplets itself, rather than
trying to come up with some new API that enforces some amount of
consistent UI.

> 3. Front End: my understanding of the current control center applets are 
> that they have a front end and back end architecture communicating via 
> XML. Would be great if we could support Python based front ends as well.

This is not at all how the control center works. This may be how the
system-tools stuff works though.

> 4. Extensible: idea of having Python is to make this really easy for 
> others to add their own Control Center applets to extend the 
> functionality as they see fit for their various distros and platforms. 
> If you need to write a back end that's OS specific then off you go as 
> they say.

There's nothing stopping them from doing this now. In fact, all of Red
Hat's system config tools are written in Python, afaik. The only current
requirements for appearing in the control center, is to have the proper
stuff in the .desktop files.

Thanks,

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Unify metacity and libwnck menu icons as named icons

[Rodney Dawes]

On Wed, 2005-10-19 at 21:40 -0400, Havoc Pennington wrote:
> On Wed, 2005-10-19 at 22:04 +0200, Luca Ferretti wrote:
> > My blue-sky is
> >   * icons are defined in libwnck and used in metacity
> >   * icons are themable via icon theme spec, not gtkrc
> > 
> 
> metacity should not depend on libwnck, but it should be simple to change
> how metacity/libwnck register these icons so they can be overridden from
> an icon theme, and in the process unify the name used for them.
> 
> Asking Owen and looking at header files I think the change in metacity
> would use gtk_icon_theme_add_builtin_icon() (use a new name like
> "gnome-maximize" here so the name is shared libwnck/metacity).
> 
> Then use gtk_icon_source_set_icon_name() to register the icon name with
> GtkIconFactory. Basically instead of registering the metacity pixbufs
> with GtkIconFactory directly, register the metacity images with
> GtkIconTheme then register the icon's name with GtkIconFactory. So the
> stock item names point to the icon theme names.
> 
> This should even be compatible with existing themes, I think...
> 
> Havoc

Is there any way to make these icons in the menus be consistent with the
buttons actually used in the title bar? If so, I would prefer a method
to make that possible, rather than having icons from the the icon theme
that don't match the buttons in the title bar.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-icon-theme branched

[Rodney Dawes]

The gnome-2-12 branch is now tagged for gnome-icon-theme off of the
2.12.1 release tag.

Be prepared for much generalization and standardization work on HEAD.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[Rodney Dawes]

On Wed, 2005-10-26 at 10:15 -0400, William Jon McCann wrote:
> Christopher James Lahey wrote:
> > What does it have if the person doesn't have a face?
> >   Chris
> 
> A bag?  No, in fact, the latest version doesn't use an image if the face 
> image is not available.

On my machine, it seems to use a horrendously scaled up version of the
image not found icon, albeit, not the one in my icon theme. This is also
an ugly thing to show, and is going to show up the majority of the time,
as most people do not set faces. It's also centered, which looks a bit
weird, given the dialog's contents. Perhaps it should be left aligned,
with the text to the right of it, and left aligned as well.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[Rodney Dawes]

On Tue, 2005-10-25 at 13:57 -0400, JP Rosevear wrote:
> On Tue, 2005-10-25 at 12:07 -0400, William Jon McCann wrote:
> > Hello,
> > 
> > I am pleased to propose gnome-screensaver for inclusion in the GNOME 
> > 2.14 Desktop release.
> 
> I'm in favour with a couple of notes:
> 
> 1. I liked the UI for unlocking circa 0.13 much better than the current
> 2. The extra settings like DPMS need to be exposed like in xscreensaver
> or move somewhere appropriate

How about...

3. Unlocking the screen with the root password should do the same as
choosing switch users, and logging in as root. Not doing so is a privacy
and security issue, as it may allow root access to remote hosts, that
root normally does not have access to.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[Rodney Dawes]

On Wed, 2005-10-26 at 16:54 +0200, Xavier Bestel wrote:
> On Wed, 2005-10-26 at 16:44, Rodney Dawes wrote:
> 
> > 3. Unlocking the screen with the root password should do the same as
> > choosing switch users, and logging in as root. Not doing so is a privacy
> > and security issue, as it may allow root access to remote hosts, that
> > root normally does not have access to.
> 
> Root has access to everything on a normal linux system.

Root on a local machine does not typically have access to all of my
remote accounts. Root may be able to su - user, and have access to all
my files, but not knowing my ssh key passphrase, he wouldn't have access
to my ssh logins on remote hosts. On the other hand, with X, and
ssh-agent, if he gains access to my session, he then has the access to
those remote hosts, very trivially.

And no, the answer to this is not "do not use ssh-agent".

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[Rodney Dawes]

On Wed, 2005-10-26 at 17:15 +0200, Xavier Bestel wrote:
> On Wed, 2005-10-26 at 17:03, Rodney Dawes wrote:
> > On Wed, 2005-10-26 at 16:54 +0200, Xavier Bestel wrote:
> > > On Wed, 2005-10-26 at 16:44, Rodney Dawes wrote:
> > > 
> > > > 3. Unlocking the screen with the root password should do the same as
> > > > choosing switch users, and logging in as root. Not doing so is a privacy
> > > > and security issue, as it may allow root access to remote hosts, that
> > > > root normally does not have access to.
> > > 
> > > Root has access to everything on a normal linux system.
> > 
> > Root on a local machine does not typically have access to all of my
> > remote accounts. Root may be able to su - user, and have access to all
> > my files, but not knowing my ssh key passphrase, he wouldn't have access
> > to my ssh logins on remote hosts. On the other hand, with X, and
> > ssh-agent, if he gains access to my session, he then has the access to
> > those remote hosts, very trivially.
> 
> Root can gain access to your DISPLAY (~/.Xauthority), your tty, your env
> vars, strace or gdb a process, etc. It can even simply kill the
> screensaver. Or install keyloggers.
> Bottom line: if you don't trust root, don't use the machine for
> sensitive data.

If someone has physical access to the machine, they can just unplug it
and walk out the door too. Doesn't mean that our software should promote
lack of privacy. If that's the case, let's just drop the screensaver
totally. What's the point if anyone can just get the data anyway?

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Custom Icons for GNOME Terminal Profiles

[Rodney Dawes]

So,

Does anyone actually use this feature? So far, it seems like most people
don't even know it exists. Most everyone I've asked so far, has said
that they didn't know about the feature, so I can only extrapolate that
it holds true for an even larger sample than I've asked.

I'd like to make gnome-terminal use the icon theme to get the terminal
icon, but I am not sure if I should just make it use the icon theme,
without removing the current extra functionality for custom icons, or
if I should just rip it out. It seems like very few people if any would
use this, and it's easy to create custom icon themes, even easier, if
I also make it comply with the naming spec. So, the best solution seems
like I should remove it, as it would simplify the UI a bit. What do
other people think?

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: High Contrast Icons

[Rodney Dawes]

On Tue, 2005-11-22 at 13:42 -0600, Federico Mena Quintero wrote:
> On Mon, 2005-11-21 at 22:40 +, Thomas Wood wrote:
> 
> > If an application calls itself "accessible", having high contrast icons 
> > should be one of the requirements. Applications are allowed to install 
> > icons into the hicolor theme; if we're really taking accessibility 
> > seriously, then high contrast themes should have a similar status to 
> > hicolor.
> 
> How do we keep applications from overwriting each other's icons?

Don't name your application the same as another application, and
namespace your icons appropriately? :) There is not really any good
answer to this I guess. The same problem has existed with hicolor for
as long as the Icon Theme Spec has been around. Applications should
ONLY be installing their APPLICATION icon to hicolor or high-contrast
though. Action, status, and other icons, should be part of the theme
for now. We really need to design a good method for doing fallback
themes and paths. The current API, in GTK+ at least, is not all that
great for doing it.

> Does this have anything to do with the relatively new icon naming spec?

One thing I hope to add to the Icon Naming spec soon, is a set of
guidelines for naming application icons, that will help to prevent
the possibility of conflicts with other app icons. Once the spec is
more filled out, and Tango and other themes implement the base icons,
we can start pushing more to get people to move to it. I've written up
a little crutch patch for libgnomeui to help us migrate a little easier,
that will be going into CVS soon. I'll also be working on patches for
other apps and libraries as well. It would be nice to have others
helping to get the spec implemented in gnome though. I don't really have
enough time to do it all by myself. :) Review and suggestions for the
spec are also quite welcome. Hopefully, I'll be able to write up specs
for deprecated icons, and extended icons for different purposes soon.
Once all this is a bit more final, we can start having reasonable sets
of icon themes whose completeness are actually defined by a document
which lists all these icons.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: High Contrast Icons

[Rodney Dawes]

On Tue, 2005-11-22 at 23:14 -0600, Shaun McCance wrote:
> On Tue, 2005-11-22 at 20:47 -0500, Rodney Dawes wrote:
> > On Tue, 2005-11-22 at 13:42 -0600, Federico Mena Quintero wrote:
> > > On Mon, 2005-11-21 at 22:40 +, Thomas Wood wrote:
> > > 
> > > > If an application calls itself "accessible", having high contrast icons 
> > > > should be one of the requirements. Applications are allowed to install 
> > > > icons into the hicolor theme; if we're really taking accessibility 
> > > > seriously, then high contrast themes should have a similar status to 
> > > > hicolor.
> > > 
> > > How do we keep applications from overwriting each other's icons?
> > 
> > Don't name your application the same as another application, and
> > namespace your icons appropriately? :) There is not really any good
> > answer to this I guess. The same problem has existed with hicolor for
> > as long as the Icon Theme Spec has been around. Applications should
> > ONLY be installing their APPLICATION icon to hicolor or high-contrast
> > though. Action, status, and other icons, should be part of the theme
> > for now. We really need to design a good method for doing fallback
> > themes and paths. The current API, in GTK+ at least, is not all that
> > great for doing it.
> 
> Then what's an application to do when it needs additional
> icons?  Yelp currently installs 10 images for admonitions
> and watermarks that can be themed.  And I intend to add
> more, whenever I get around to it.  All of the filenames
> start with the yelp- prefix, so they're relatively safe.
> But unless there's a good recommendation on how to name
> such things, problems are going to arise.
> 
> Note that Yelp currently doesn't install these into hicolor.
> Instead, it puts them into $(datadir)/yelp/icons and calls
> gtk_icon_theme_append_search_path.  And while that's fine
> for avoiding conflicts in hicolor, it doesn't help us when
> themes need to override the defaults, as our a11y themes
> certainly would want to.

It seems to me like these things would be useful not only to yelp, but
other desktops' help browsers as well. We should probably come up with a
common set of names if they belong in the icon theme, or a common help
documentation theming method. Or both. It would be very useful to have
a common method for theming the documentation through stylesheets. I
think the closest thing we have now, is to just patch the stylesheets in
the help browsers at build time.

-- dboey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Custom Icons for GNOME Terminal Profiles

[Rodney Dawes]

Thanks for the bug info. I've attached a patch to the bug in question,
which removes the setting entirely, and replaces it with usage of the
icon theme.

-- dobey

On Sat, 2005-11-19 at 01:45 +0100, Olav Vitters wrote:
> On Fri, Nov 18, 2005 at 07:27:31PM -0500, Rodney Dawes wrote:
> > Does anyone actually use this feature? So far, it seems like most people
> > don't even know it exists. Most everyone I've asked so far, has said
> > that they didn't know about the feature, so I can only extrapolate that
> > it holds true for an even larger sample than I've asked.
> 
> I did use it in the past for a Mutt profile, but currently don't
> bother. Think removing the icon is a good idea. Bugreport about this
> misbehaving icon:
>   http://bugzilla.gnome.org/show_bug.cgi?id=126081
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: High Contrast Icons

[Rodney Dawes]

On Wed, 2005-11-23 at 13:48 -0600, Shaun McCance wrote:
> Back on topic: Real applications in the wild are absolutely
> going to need to install some application-specific icons
> for various actions or data that are unique to those apps.
> Even if a sizable percentage of those icons are things we
> could manage to abstract into generic icons, third-party
> developers aren't going to wait around for new releases
> just so their applications can function.  It's great that
> we've finally managed to make progress on standard icon
> naming, and I applaud everybody who's been involved with
> that effort.  But it's important we have a recommendation
> for random application-specific icon names.

Then real applications shouuld install those icons into a private
data directory. There's no point in installing them into the theme
if other applications don't need them. We are trying to create a
very large list of icon names that should be used for specific purposes.
We are also trying to deprecate some icons, so that we can reduce the
number of icons in use throughout the desktop overall. The sheer number
of icons we have already, is quite overwhelming to both the user, and to
theme developers and artists.

Application specific things should go into application specific
directories. In that sense, what yelp is currently doing is the right
way to do it, if other help browsers aren't going to use them. App icons
though fall into two categories. There are icons for standard desktop
accessories and utilities. File manager, help browser, calculator,
terminal and a few others fall into this category. Then there are app
icons which should be branded. Things such as web browsers, mail,
calendar, and similar applications, fall into this category. While it
probably is not the case that another application will need to use an
app's icon as its own, it is the case that other applications will need
to display those icons. This is the reason for them being installed to
the hicolor theme. The Icon Theme spec is not particularly clear on this
subject, but it was designed around the need to have app icons work in
the menus properly on both desktops, without copying the icons to a
bunch of different places.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: High Contrast Icons

[Rodney Dawes]

On Wed, 2005-11-23 at 15:08 -0600, Shaun McCance wrote:
> But that only avoids conflicts when the icon isn't overridden by
> an icon theme.  The original point of the thread is that we should
> be providing HighContrast and HighContrastInverse icons whenever
> we provide hicolor icons.  I can put Yelp's application-specific
> icons in DATADIR/yelp/icons, but that only provides my fallback
> icons.  What's Yelp to do about the a11y versions?
> 
> I suppose I could put in a one-off check if the user's icon theme
> is HighContrast and HighContrastInverse and adjust the icon search
> path in Yelp accordingly (like, say, DATADIR/yelp/hcicons).  But,
> you know, ewww.

I'd have to say that is the correct way to deal with it. Everything
in the world isn't pretty. And the attitude put forth in your previous
posts tells me that you'd be less than comprimising when it came to
trying to make the use cases consistent between yelp and other help
browsers.

As I said previously, the GTK+ API is perhaps not the best thing in the
world when it comes to handling cases like this, and fallbacks. The
correct way to fix this is to decide what's wrong with the API exactly,
design a way to fix it, and just fix it, not to implement workarounds by
just installing the files somewhere else, so you can make the API easier
to use for you as a developer. The workaround sucks in terms of release
engineering, and the API is annoying in terms of development. Let's look
into fixing the API for developers, not making stuff more of a pain for
packagers because the API is annoying and makes you say ewww.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Yelp patches

[Rodney Dawes]

I'll just point out that libgnomeprint* are going away in the near
future, in favor of printing support in GTK+ proper. While I'm sure
the patch is fine, and the work is greatly appreciated, it is a bit
of a weird time to be trying to add the support in. Would just be a
bit of a pain to add printing support, and then have to immediately
replace it with the new printing API, if we go with GTK+ 2.10 for
GNOME 2.14, presuming that the printing is going into GTK+ 2.10, as
part of the Project Ridley work.

-- dobey


On Fri, 2005-11-25 at 11:48 +, Don Scorgie wrote:
> The first is to add printing support using libgnomeprint* and the second
> improves startup time with man pages.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Yelp patches

[Rodney Dawes]

I wasn't suggesting that it keep the patch from going in. I was just
pointing out that printing was something that would be moving into
GTK+ and libgnomeprint* would be going away, so that people who probably
need to know about it (ie, people implementing printing) would know. If
the right thing to do is to put in the patch, and rewrite the code
against the new API later, then so be it. Was just makign a PSA about
the future of printing in GNOME/GTK+. :)

-- dobey

On Fri, 2005-11-25 at 11:43 -0500, Matthias Clasen wrote:
> GTK+ 2.10 is not going to be ready in time for 2.14, and things which 
> only exist on a GTK+ roadmap should not keep working patches from 
> going in.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Another way to solve the Spatial vs. Navigational debate

[Rodney Dawes]

I really really like how Windows solved this problem. There is an option
to open all folders in the same window, but which is not the full blown
Explorer browser mode interface. It's basically spatial, but ignoring
the per-folder window position/size/etc... stuff. Before XP and maybe
even Win2k (I don't remember about it), Windows in fact, would be
spatial when opening folders through icons on the desktop (or shortcuts
to folders in menus), and only use the browser interface, when you run
explorer by hand or open it from the start menu. Accompanying that
behavior, is also a menu item "Open in New Window". I think Nautilus
already has this item in the browser mode UI.

This does two things. It lets the interface stay simple (no location
bar, no toolbar, no sidebar), and keeps a large number of windows from
opening, to frustrate the user. It might be nice to do this for the
default in Nautilus. It's a nice middle-of-the-road solution, and I
think it solves most of the problems that users have with the current
spatial behavior.

-- dobey


On Fri, 2005-12-23 at 10:23 -0800, Sriram Ramkrishna wrote:
> Why not have a group split off and try to solve the "too many
> windows problem"?  Or maybe advertise to universities on what might
> be a great master's thesis.
> 
> sri

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GConf --makefile-uninstall-rule is incompatible with packaging systems

[Rodney Dawes]

On Tue, 2006-01-10 at 09:53 -0500, Havoc Pennington wrote:
> On Tue, 2006-01-10 at 12:49 +0100, Stanislav Brabec wrote:
> > 
> > 4. Enhance GConf:
> > 
> 
> 
> The right fix IMO is that apps should parse the schema files
> client-side, and don't "install" them to the gconf source at all.
> 
> See: http://www.gnome.org/projects/gconf/plans.html
> 
> This has a bunch of advantages, among them simplifying packaging.

Agreed. Although, it doesn't really work for a more immediate solution,
which I think Stanislav is looking for.

According to the RPM documentation, the way to handle this currently,
is unfortunately, to do the --makefile-uninstall-rule in the %pre of
the new package, if it's an upgrade, or in the %preun of the package,
in the event of straight package removal.

I'm not sure what the best method for dpkg or other systems would be
though. Hopefully less nasty.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GConf --makefile-uninstall-rule is incompatible with packaging systems

[Rodney Dawes]

On Tue, 2006-01-10 at 20:59 +0100, Josselin Mouette wrote:
> Le mardi 10 janvier 2006 à 11:23 -0500, Rodney Dawes a écrit :
> > According to the RPM documentation, the way to handle this currently,
> > is unfortunately, to do the --makefile-uninstall-rule in the %pre of
> > the new package, if it's an upgrade, or in the %preun of the package,
> > in the event of straight package removal.
> 
> This looks fragile, as you have to keep track of all previous versions
> of the packages to handle upgrades.

I'm not sure this is true, but I am not totally certain it isn't. I
would hope that there is some way to check if an upgrade or simple
removal is happening.

> For the record, what is the reason why rpm doesn't run the pre-removal
> script before upgrading ?

I don't know. I didn't write it. Although, if you find the answer, it
would be great to know why it is so nasty.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: ~/.gnome2/share/fonts

[Rodney Dawes]

I believe this is from libgnomeprint.

-- dobey

On Tue, 2006-01-17 at 16:29 +0100, Rodrigo Moya wrote:
> Hi
> 
> What is ~/.gnome2/share/fonts for? What programs/libs access it?
> 
> Bug: http://bugzilla.gnome.org/show_bug.cgi?id=310089

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

That's right. Only Kenya [1] has lions, and only GNOME has over 1200
uniquely named icons, in its default theme. In an effort to improve
the maintainability of gnome-icon-theme, I've spent most of this past
weekend preparing it to migrate GNOME to the Icon Naming Specification,
make the default theme be much more generic, and help clean up the UI
a bit, by helping to get rid of extraneous icons.

As a result of these changes, our wonderfully talented icon artist,
jimmac, is actually interested in fixing up some icons in the default
theme again. Also, gnome-icon-theme now, and until the desktop is
entirely migrated to the Icon Naming Specification, and it is much
more complete and finalized, will depend on icon-naming-utils [2]. As
changes happen in both the theme, and naming utilities, the version
requirement will be bumped, so that the backward compatibility may
remain optimal. 

Many more releases will follow swift and often, between now and 2.14.0.
Enjoy.

-- dobey


[1] http://www.weebls-stuff.com/toons/kenya/
[2] http://tango-project.org/Standard_Icon_Naming_Specification


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 14:14 -0500, Matthias Clasen wrote:
> So, lets talk about this new dependency, icon-naming-utils. There
> is a couple of issues here:
> 
> - The jhbuild gnome 2.14 moduleset does not know about it

This is a trivial problem then. Let's fix it. I don't use jhbuild, so
I know not where things get changed to add modules to it.

> - It does not have a bug tracker, or 'canonical' tarball location

The current canonical tarball location is on the Tango site at
http://tango-project.org/releases/ . Bugs currently get filed against
the tango product in http://bugs.freedesktop.org/ , however, that does
need some re-organization.

> - It installs things in SuSE-specific locations like /usr/share/dtds, and
>   scripts in /usr/libexec

Nothing about the script is SuSE specific. It installs the dtd to
$(datadir)/dtds, because having a bunch of separate directories each
with one or two dtd files, seems kind of silly to me, in a release
engineering, and emacs-using perspective. And installing to
$(libexecdir) is hardly specific to SUSE, given that we specify
different libexecdir paths for all of our packages. It installs it in
libexecdir, because that's where it should be. It is not meant to be
run by users by hand. It is meant to be run by the Makefile rules at
make install time. However, nothing about it is specific to SUSE. So,
please don't try to pull the distro-war card. Foresight ships Tango as
the default theme even, and Tango has used icon-naming-utils since the
beginning.

> - It uses perl-XML-Simple, unlike other perl utilitites like intltool, which
>   use perl-XML-Parser. This is a problem for us, since perl-XML-Simple is
>   in Fedora Extras atm.

Well, the difference in complexity between Simple and just Parser is an
order of magnitude of difference, in terms of code, and I personally am
not going to change it, just for Fedora. This is a build-time only
dependency, and not a runtime depdency. I can't keep up with what every
distro out there ships, and in what level of the distro they ship it in.
The size of XML-Simple is extremely small, as well. If you're willing to
write a patch to use XMl-Parser instead, and maintain it, then we can
talk about that separately I guess, but I see no reason to do it for
something so simple as reading an XML file into a hash to loop over.

-- dobey



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 20:37 +0100, Vincent Untz wrote:
> Hi Rodney,
> 
> Le mardi 17 janvier 2006 à 12:59 -0500, Rodney Dawes a écrit :
> > That's right. Only Kenya [1] has lions, and only GNOME has over 1200
> > uniquely named icons, in its default theme. In an effort to improve
> > the maintainability of gnome-icon-theme, I've spent most of this past
> > weekend preparing it to migrate GNOME to the Icon Naming Specification,
> > make the default theme be much more generic, and help clean up the UI
> > a bit, by helping to get rid of extraneous icons.
> 
> Will there be an easy way to update all our modules so they use the new
> icon names? If we migrate right now, I'm pretty sure some modules won't
> find some icons because they were renamed.

I'm going to try and get a gallery status page up on gnome.org
somewhere, like we have for the tango theme, soon, which will help
show which icons are done in the theme, and what names are in the
spec. However, there's no easy way to just fix all the code to change
the icons that are being looked up. The latest versions of GTK+ and
libgnomeui look up icons for MIME types through the naming spec style
first, and then fall back to the old gnome style. Also, the
icon-naming-utils script creates a large number of symlinks at install
time, to preserve backward compatibility. So, despite the fact that
the actual icon files have changed names to comply with the spec, the
apps should all still work, and will make the transition much more
smooth.

I plan to patch gnome-applets soon though, so that it uses the new
names in gweather. Also, one of the ideas as I stated in the
annoucement, is to help reduce the overall number of icons used in
the desktop. So, some icons currently in use, may be better off, were we
to get rid of them. But this is part of the work in getting the spec up
to par with what is really needed, and migrating the desktop over. In
the end, I think all this work is going to be very profitable [1] for
us, as a free software project and community.

-- dobey

[1] profitable in the communist sense, without monetary exchange


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 13:23 -0700, Elijah Newren wrote:
> This shouldn't be looked at as a 'just for Fedora' thing.  Addition of
> external dependencies to release set modules is subject to community
> approval and we do have precedent of not allowing hard dependencies on
> modules that maintainers would have otherwise used.  It only makes
> sense because we don't want an explosion of external dependencies. 
> Given Matthias objection, it is something we'll have to push for
> general consensus on.

Fedora's organization and structure is specific to Fedora. Several
distros are already shipping a theme which depends on icon-naming-utils,
some as the default, and not a single one of them has complained to me
about the dependency on perl-XML-Simple.

As far as modules that otherwise would have been used, there are none
that I would have otherwise used, unless I had written the code in C
instead of perl. I wrote it in perl, because of XML::Simple. It's not
exactly Yet Another Parser as Matthias seems to claim. It is simply an
abstraction on top of XML::Parser, which we already depend on, to make
the handling of XML for simple tasks such as that which
icon-naming-utils undertaks, very easy and simple to code. It's still
using XML::Parser, which is still using expat.

And as for the dependency on icon-naming-utils, I also maintain it, and
there is no other script which handles the task that it does, so it's
not like I picked some random thing and decided "oh, we need to use
this." This is a very much needed tool at this time, and we need to work
on the transition to the new spec now.

If the XML::Simple thing is really that much of a problem, then may who
claims such produce a patch that replaces it with pure XML::Parser, that
may prove fit to supplant the current code in CVS. 

If the icon-naming-utils dependency in total is also really that much of
a problem, then may you supplant gnome-icon-theme 2.13.x with 2.12.1 for
the 2.14 release of GNOME. Or I can backport a few fixes, and release
newer versions of 2.12.x for 2.14 as well.

This was all done in time for feature freeze, because well, it's a
feature. If the latter be the decition of the release team, then so be
it, but HEAD gnome-icon-theme is going to continue moving toward
compliance with the Icon Naming Spec. It needs to be done sooner rather
than later, and the approximately 72 hours I spent working to make it
happen, shall I not let go gently into the night, because of a tiny
little perl module dependency.

-- dobey



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 15:55 -0500, Matthias Clasen wrote:
> > I may be able to get perl-XML-Simple pulled into FC2, even if we
> > normally don't allow new packages after test2. But regardless of that,
> > it sucks to use *yet* another perl parser, just
> > because we haven't used them all yet...
> >
> 
> Ok, this is getting interesting, perl-XML-Simple drags in
> perl-Tie-IxHash, lets see
> how much of the perl universe will end up getting caught by this
> innocent dependency...

Perhaps this is a packaging issue? It certainly doesn't depend on that
module here [1], or any machine I've ever installed it on before. And
according to the source listing on cpan.org, it seems to only require
XML::SAX or XML::Parser, which then also depend on other things, such as
Storable, or dependencies provided by the perl source itself.

-- dobey

[1] perl-XML-Simple 2.14 on unstable SUSE/Novell packages


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 20:38 +, Richard Hughes wrote:
> On Tue, 2006-01-17 at 15:15 -0500, Rodney Dawes wrote:
> 
> > I plan to patch gnome-applets soon though, so that it uses the new
> > names in gweather.
> 
> 
> So what's the easiest way for a maintainer to scan his src/ directory
> identifying the old names, and suggesting replacements?
> 
> For instance, for g-p-m a script would be really handy that searched for
> "gnome-dev-acadapter" and suggested a replacement.

There's no particularly easy way to check for icon names. Some of the
names get passed in from libraries, or other pieces of code, as
variables, some are defines, some are string literals. I think the
"simplest" way, would be to patch GTK+, and have it check if the
requested name is in the spec somehow, probably a hash table, and if
not, then spew a warning. A lot of icon names that are in use, are
seemingly quite random as well, which makes it even harder to determine
by script if an icon name makes sense or not, since you can't just grep
for things that you don't know about already. :)

However, I am totally willing to help deal with questions about icons
with regards to the spec, and how to improve things. So, if you can
comprise a list of icons being used, and describe what they are being
used for, and where, and send me e-mail asking for help, I'm sure we
can move ahead in the right direction nicely. :)

> Or are we supposed to just reply on the compat symlinks?

The compat symlinks are there so that applications won't break during
the transition. Also, very few icon themes are actually ported
currently, so I think relying on the compat links for the time being
is not a bad thing entirely. 

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 23:23 -0500, Matthias Clasen wrote:
> Are we silently switching to Tango here ?

I wish, but no. Jakub is updating several of the icons to have a more
modern look, by applying elements from the Tango Style Guide, to the
gnome-icon-theme style icons.

I've explicitly instructed him to keep the gnome and tango icons
different. There are several reasons for this. There are licensing
differences between Tango and g-i-t. We are trying very hard to get
people from KDE and other desktops interested as well, and simply
putting Tango icons in would only back up their arguments that it is
heavily GNOME based.

However, simply applying some of the bits of the Tango Style Guide,
such as the lighter inner hint, palette choices, and the like, can
improve the icons on one's desktop quite a bit. Andreas, who has been
helping out with the Tango icons, and has helped out previously with
GNOME icons, has even redrawn a couple of KDE icons, using the Tango
Style Guide. Needless to say, they look amazing.

But, if everyone thinks he should not update the GNOME icons, I'm sure
we can revert back to the old, drab, incomplete, and unmaintained style.
Frankly, I'm all for keeping my artist happy, though.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Icon Theme 2.13.5[.1] AKA the HOLY CRAP, ICONS! release

[Rodney Dawes]

On Tue, 2006-01-17 at 21:46 +0100, Emmanuele Bassi wrote:
> I was about to open a bug for it, but I'll mention this issue here
> anyway: the current "gdict" icon should be deprecated and deleted from
> the theme, since gnome-dictionary ships its own.

Great. This is actually what we want to do with app icons. For things
like gdict or gnome-terminal, it kind of makes sense to have generic
icons, as little utilty applications like these, tend to be part of the
desktop. But for things like Evolution, Epiphany, and Firefox, it is
best to have a branded application icon, so it's easier to distinguish
the items in menus, by means other than simply text.

> Also, I'd need some of the fine GNOME icon artists to give it a spin
> (I'm no icon artist, nor expert of Inkscape whatsoever, so the current
> icon[1] still kinda sucks).

Hrmm. That icon looks like it's done a bit in the Tango style already.
Did Andreas draw that? It's pretty nice icon, visually speaking. But,
the metaphor is lacking. The connection between book and dictionary is
loose, as there is no text or other symbolic imagery on the icon. We've
been tring to come up with a better metaphor for dictionary, than simply
book, but haven't come up with anything concrete yet. You're welcome to
join #tango on freenode or mail the tango-artists list, and discuss
possible solutions to the dictionary metaphor problem, so that maybe we
can have an amazingly nice icon for the dictionary.

I suggest the tango list and channel here, as standarized metaphors is
also something we want to add to the naming spec, so that it may help
artists create icon themes in the future, prevent icon ambiguity, and
allow applications for various desktops and toolkits interoperate better
on a design level.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Splash screen + desktop background + gdm theme for 2.14

[Rodney Dawes]

If we're still using splash screens in 20 years, then $DIETY help me...

-- dobey


On Sun, 2006-01-22 at 04:44 +0100, Tino Meinen wrote:
> In 20 years we can organize contests during GUADEC to match the images
> with the numbers! Wheee!
> 
> Tino


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: control-center 2.13.90 released

[Rodney Dawes]

On Mon, 2006-01-30 at 13:54 -0700, Elijah Newren wrote:
> It's worth noting that the only applicable reason from that page for
> not making it instant apply is that it took longer than a second. 
> It's worth noting that several have commented in
> http://bugzilla.gnome.org/show_bug.cgi?id=327335 saying that we should
> look at making it faster, since it's close to a second (and for
> several people is faster than a second) anyway.  For those of us for
> whom it is faster than a second, this change is a HIG violation
> AFAICT.

No, read my mail to announce the changes to the appropriate lists. Both
reasons are valid. All of the settings in the dialog get applied at the
same time as well. So, the HIG still suggests it should be explicit
apply, even if it is fast for you.

It was done to follow these two suggestions in the HIG, as well as to
help address users experience confusion with the "Close" button, as was
discovered in some of the usability tests we conducted for
BetterDesktop. The "Close" button, ironically, did not give several of
the users in the tests, the feeling of closure.

I'd have to go through the videos again, to see which ones that are
on the site, and stated this, though. I should be able to do that soon
to answer that question if it's now dwelling in the back of your head,
as well as to answer Bryan asking it in the bug report you mention.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: control-center 2.13.90 released

[Rodney Dawes]

On Tue, 2006-01-31 at 12:49 +, Calum Benson wrote:
> On Mon, 2006-01-30 at 13:52 -0700, Elijah Newren wrote:
> 
> > I also feel that it looks odd and out of place (Why else would I click
> > on a different image than to have it be my background?).  It appears
> > this was done because the change was too slow -- at least that's the
> > valid reason I could find at
> > http://bugzilla.gnome.org/show_bug.cgi?id=327335.  I'm with Federico
> > though in thinking we should make it fast instead.
> 
> And in the meantime, a bit of pointer feedback would probably relieve
> any "why is nothing happening?" symptoms on the instant-apply front.

The gnome-background-properties dialog has no idea how long it will
actually take for the settings to take effect, as it does not control
the actual drawing on the background. The gconf calls to set the keys
succeed and return instantly, which means that changing the pointer in
the capplet itself, based on that information, would be totally useless.
A timeout would still be needed, to slow the UI down.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: control-center 2.13.90 released

[Rodney Dawes]

On Tue, 2006-01-31 at 10:49 -0600, Federico Mena Quintero wrote:
> On Tue, 2006-01-31 at 10:14 -0500, Owen Taylor wrote:
> 
> > I think the first step is for someone to simply spend a little time
> > figuring out what is slow:
> > 
> >  - Gradients
> >  - Scaled images
> >  - Solid color backgrounds?
> > 
> > If we are scaling images *via Cairo* that is known to be slow with
> > older X servers; if investigation proves that actually is the problem,
> > it can be worked around.
> 
> I'm pretty sure that this is the same bug as
> https://bugs.freedesktop.org/show_bug.cgi?id=4320
> 
> At Suse we have Stefan Dirsch looking into that particular bug.  This
> may help the capplet, but again, someone needs to profile the capplet to
> see what is going on.
> 
>   Federico

Profiling the capplet won't help at all. It's not actually doing any of
the drawing on the desktop. Someone needs to profile nautilus and/or the
gnome-settings-daemon processes. These are the places where the drawing
happens. Albeit much faster without nautilus running, it could probably
still stand to see a little bit of improvement. A quick test by quickly
changing some background images on my old Powerbook G3 (400 w/192 MB
RAM, on OS 10.2), showed that it still seemd a bit faster than we are,
even without nautilus managing the desktop.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: control-center 2.13.90 released

[Rodney Dawes]

On Wed, 2006-02-01 at 17:49 +, Alan Horkan wrote:
> > From: Davyd Madeley <[EMAIL PROTECTED]>
> > To: Rodney Dawes <[EMAIL PROTECTED]>
> > Cc: Desktop Development List ,
> >  Calum Benson <[EMAIL PROTECTED]>
> > Subject: Re: control-center 2.13.90 released
> >
> > On Tue, Jan 31, 2006 at 08:58:22AM -0500, Rodney Dawes wrote:
> > > On Tue, 2006-01-31 at 12:49 +, Calum Benson wrote:
> > > > On Mon, 2006-01-30 at 13:52 -0700, Elijah Newren wrote:
> > > >
> > > > > I also feel that it looks odd and out of place (Why else would I click
> > > > > on a different image than to have it be my background?).  It appears
> > > > > this was done because the change was too slow -- at least that's the
> > > > > valid reason I could find at
> > > > > http://bugzilla.gnome.org/show_bug.cgi?id=327335.  I'm with Federico
> > > > > though in thinking we should make it fast instead.
> > > >
> > > > And in the meantime, a bit of pointer feedback would probably relieve
> > > > any "why is nothing happening?" symptoms on the instant-apply front.
> > >
> > > The gnome-background-properties dialog has no idea how long it will
> > > actually take for the settings to take effect, as it does not control
> > > the actual drawing on the background. The gconf calls to set the keys
> > > succeed and return instantly, which means that changing the pointer in
> > > the capplet itself, based on that information, would be totally useless.
> > > A timeout would still be needed, to slow the UI down.
> >
> > At this stage in the game, I think we should look at doing three
> > things:
> >  (1) reverting the UI change, it is a bandaid fix to a deeper
> >  problem;
> 
> If the hope is to change it back when things get faster then this current
> change is inflicting unnecessary software churn on users.

The hope is to fix all of the problems. Not following the HIG is
something that I would consider a problem. I fixed the dialog to follow
the HIG. And the oversimplification of the problems into "i think it's
ugly, so we shouldn't do this" is just silly. The change was not done
solely to work around the performance issue. Any claims that it was, are
obviously misinformed and oversimplifying the set of problems that the
change was meant to solve.

> As I'm on older crappy hardware I guess I should sit out this release
> cycle entirely as an even slower Gnome would probably kill it.
> 
> >  (2) shipping GNOME 2.14 with gtk-engines 2.6, leaving people who
> >  giving us more time to optimise gtk-engines/cairo/X
> 
> I expect this would be unpopular with developers (especialy dobey).
> How many developers have really crappy hardware?  (ie > 3 years old)

I could care less what version of gtk-engines we ship. It's not the
problem, and I don't use any of the engines in it anyway. I doubt that
the problem is even the fact that gtk+ uses cairo. Cairo can fill a
full-screen rectangle on my crappy 3 year old Radeon 7500 in about
0.0007 seconds. That's also with X 6.8.2. On my Radeon FireGL X1 at a
lower resolution, on X 6.9.0, it takes about 0.007 seconds for the same
test case code that Federico pointed me to, to run. That's significantly
slower, for a significantly better video card. However, in both cases,
the amount of time taken, is nowhere near the amount of time it takes to
actually render the background. I don't know why gtk-engines was even
mentioned in this thread, or why Davyd alluded to it being the cause of
the slowness, on his blog.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: breakage caused by removed icons from gnome-icon-theme

[Rodney Dawes]

On Sun, 2006-02-05 at 15:04 +0100, Christian Persch wrote:
> Hi,
> Le samedi 04 février 2006 à 23:14 -0500, Matthias Clasen a écrit :
> > On 2/4/06, Christian Persch <[EMAIL PROTECTED]> wrote:
> > > The latest gnome-icon-theme release has removed the "gnome-spinner" and
> > > "gnome-spinner-rest" themed icons, causing breakage in (at least)
> > > epiphany, nautilus, gedit and beagle. Other people have told me that
> > > other removed icons also cause problems in nautilus and deskbar-applet.
> > > This removal needs to be reverted.
> > 
> > Do you have a list of those other removed icons ?
> 
> I downloaded the 2.12.1 and 2.13.6 tarballs from ftp (you can see from
> the size differences alone that it's a huge removal, 2.12.1's .bz2 is
> 3MB, and 2.13.6 only 2MB!), installed in different prefixes, and did a
> bit of find + diff magic, and the result seems to be that 187 icons
> names that are in 2.12.1 are not in the 2.13.6 install either as regular
> file or symlink (list attached).

But this list does not show which icons are in active use. It simply
shows a list of files that were removed. I guarantee that there are a
lot more than 187 icons in gnome-icon-theme that aren't even being used.

> > > The new g-i-t has already been discussed here,
> > > http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00302html,
> > >  but insufficient emphasis seems to have been made about backward 
> > > compatibility. While participants have asked about how to upgrade their 
> > > apps, we should instead ask what happens when the user upgrades g-i-t, 
> > > but does not simultaneously upgrade all his apps (apps which may not be 
> > > maintained anymore, even!).
> > >
> > > Arguably the icon names provided by gnome desktop's gnome-icon-theme are
> > > part of some sort of ABI; should they therefore part of our ABI
> > > stability guarantee?
> > 
> > Yes, at least we should avoid shooting our own foot by removing icon names 
> > that
> > are in active use by gnome applications. Time to revert to
> > gnome-icon-theme 2.12 ?
> 
> IMO yes.

Someone should file some bugs then. Just complaining that /some/
icons /may/ be missing isn't going to get it fixed. And, fwiw, the
ABI stability guarantee doesn't seem to apply to the desktop, but
only the developer platform. And gnome-icon-theme is part of the
desktop, not the developer platform. Also, gnome-icon-theme was
never guaranteed to be in the fallback icon path. It has only ever
been the /default/ icon theme, in very informal informal and ugly
ways. But I've also improved that for 2.14, and while the settings
daemon is running, with gtk+ 2.8.10 or later, the "gnome" theme will
always be searched for icons, before hicolor.

If someone can actually provide a list of what all icons are actively
in use for real, I would love to see it.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: breakage caused by removed icons from gnome-icon-theme

[Rodney Dawes]

On Sun, 2006-02-05 at 14:31 +0100, Raphael Slinckx wrote:
> For deskbar we were using for example "stock-my_documents" named icon,
> to represent file & folder searching. It's gone, so i had to replace it
> by GTK_STOCK_OPEN. The previous icons indicated better what it was all
> about..

If the icon is used to show something in the user's "Documents" folder,
then you should match icons with that folder, not with what you think
would be best used for that folder. GNOME does not use special icons for
special folders like Documents/Downloads/Music/etc... I would suggest
just using the standard folder icon, or querying the Nautilus metadata
for the folder in question to get a custom icon if one is set, and to
use emblems if available. Although, at the size you are probably using
that icon, emblems would probably be bad.

-- dobey

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list