Deferred Edgy Ideas for Feisty

[Jani Monoses]

Thanks for bringing this up, it's a good way for people to get an 
overview of what was done in Edgy and what may come in Feisty and more 
importantly find out if they can contribute.

> Lets take a walk through 
> https://wiki.ubuntu.com/Xubuntu/Specifications/Edgy/Ideas and see what 
> we can take from there and implement in Feisty:
> 
>     New printer configuration (either adding this to xfprint or making
>     gnome-cups-manager gtk-only) 
> 
> 
> Implemented in Edgy.

As Gauvain said it's the Fedora tool neither g-c-m or xfprint, but 
nonetheless it is implemented. The main problem in dapper was that a new 
printer can only be added by either the CUPS web interface or editing 
the config files, but both approaches require command line usage.

On this matter Ubuntu Feisty is planning to get printerdrake (from 
mandriva, and with the help of Till Kamppeter) to replace the 
unmaintained gnome-cups-manager. I'll keep tracking 
system-config-printer from Fedora upstream but we may switch to 
printerdrake (gtk2 perl) if it is better and if Ubuntu switches too.

Another thing I filed a bug on upstream is making mousepad use the 
printing API of GTK2 as it is AFAIK the only user of the xfprint4 
command line tool and then we could drop the latter.

> 
>       Browse Windows network (Thunar)
> 
> 
> We might not be able to get something integrated with Thunar for Feisty 
> but we could include a stand-alone samba network browser. I hear there 
> is a nice python based one.
> 

Benedikt Meurer (thunar upstream) said in a ml thread that he'd like to 
get this done for next xubuntu release but as usual no promises.
fusesmb means using the command line, what we want is something like 
nautilus' behaviour.

If that does not happen in a few months we may need to promote something 
from universe like the xffm or the python tool mentioned.

>     Floppy support (Thunar) 
> 
> 
> I'm sure it wouldn't be hard to hack this into Thunar. <g>

I think it actually works for some people from what I read on the 
thunar-ml? It may not have been integrated with HAL or some similar
friendly aspect was missing, it will need investigation.

> 
>     sort out Audio/Video player situation (gxine looks better that
>     xfmedia at this point) (I would suggest seperate clients for audio
>     and video: something like Listen or Exaile for audio, and gxine/xine
>     for video)
> 
> 
> Should we re-evaluate this again?

For video player we'll stick with gxine. A separate audio player will be 
evaluated only if it is 1) packaged in universe 2) conforms to the 
dependency requirements 3) it is stable and actively maintained (as 
opposed to actively rewritten from scratch) by upstream 4) looks and works.
So candidates should only be proposed on the list after they meet these 
criteria, preferably by the person who intends to take care of it and 
its bugs in ubuntu :)

> 
>     Update-notifier to be included by default.
> 
> 
> I haven't looked. Did this make it into Edgy? If not, we could fix the 
> xfce notification daemon (it has the gnome-deps removed) and update the 
> update-notifier to make use of it. Shouldn't be too hard.

notification-daemon is ok it has no gnome depends only libwnck which is 
tiny. I think the xfce notification daemon project is not having enough 
benefits to outweigh the dull work of maintaining yet another duplicate 
of a gnome package.
> 
>     Menubar like in Gnome (Apps/Places/System) instead of simple menu
>     (Applications)
> 
> 
> This, however, is something we could easily do and an idea that I like.

Not easily but we could do. I contemplated this both for dapper and edgy 
and what kept me back is is not the UI part which may be simple enough, 
but the fact that the xfce menu is not fully compatible with the gnome 
one (XDG menu spec) and getting that layout may need some new 
(incompatible?) features added to how the menu stores its entries.
There's a new XDG compliant menh module in the works upstream planned 
for Xfce 4.6 which could be starting point for a new menu plugin but 
it's not ready yet.
> 
>     All of Reducing duplication, reusing Ubuntu software
> 
>  
> Did you ever solve the CDBS issue? Any further efforts here?
> 

As Gauvain said he's working on the multibuild.mk CDBS class so it can 
be reused in packages that have --disable-gnome as a configure option.
It was used for gcalctool in edgy and hopefully will be used in more 
packages for feisty.
I was going to send a --disable-gnome patch to upstream 
gnome-power-manager but it just got harder as it recently added extra 
dependencies because of gnome panel applets, so that may not become a 
feisty feature for us after all.

>     Import upstream svn into bzr in LP and work on that
> 

thunar, xfdesktop4, xfce4-session,xfwm4 and xfprint4 are tracked with 
bzr now for example see
https://launchpad.net/products/thunar/trunk

So if anyone plans coding on them can keep an up-to-date branch easier 
than with upstream svn. But that does not look like the case as we do 
not have yet any major divergence except the session power management 
hack which as not yet in bzr ( I should add them there I think)

Anyway low priority, but if it got actual use and turned out good it may 
make sense for non-ubuntu xfce contributors. I think Xfce was the first 
desktop to switch from CVS to svn and I see no reason why they should 
not lead the way with the adoption of a distributed/disconnected tool ;)

> Do we plan to still do this?
> 
>     Xubuntu langpacks? Right now it's base langpacks + gnome langpacks
>     (evince, gnumeric) for full desktop translation
> 
No, this turned out to be unnecessary, we have enough gnome apps in the 
install that we need gnome-langpackas anyway. There's no way to 
completely erase a spec from LP so this is set to what is closest to 
obsolete/unneded I think.

> 
>     Revisit app selection (i.e. sylpheed-claws vs t-bird vs seamonkey)
> 
App selection is a constant process, but it is also the most 
disorganized as some apps proposed do not meet the criteria at all.
This is not the case with claws of course, but except from being 
proposed by its upstream developer and its obvious speed when compared 
to tbird there were not many voices in support of it. I am particularly 
concerned about bug count and maintenance in ubuntu. T-bird is 
maintained by someone else so we get it for free :)

Jani