radiotray-devel Mailing List for Radio Tray

Hi everybody,

This mailing list as been pretty much dead. In part is my fault, but my
conclusion is that it hasn't become a very good communication channel for
all developers to communicate.
Right now, this list is not open and only available to anyone that
contributed (well, not all, but at least some) to RT.
I'm thinking of opening this mailing list, so that anyone can freely
subscribe. Of couse, the purpose of the mailing list becomes different. Not
only can and should still be for discussing RT development, but it will
probably be used mostly by people asking for help, suggesting stuff or even
offering help. Nevertheless, I think this will help us communicate better
with RT users, as we don't have a forum and my blog is hardly the best
place for that (apart from being flooded by spam lately).

So, first I want to ask you if everybody agrees with this ?

And second, do you have any other suggestion for this subject ?



Thanks in advance,
Carlos Ribeiro

Hi everybody,

Just a quick note to tell you that I just released 0.6.4, a bugfix only
release.
As always, thanks for all the help and support.


Cheers,
Carlos Ribeiro

Hi all,

Finally, a lot of issues with translations seem to be solved and transifex
updated accordingly. I'm going to blog about it, asking for updates to the
translation files and then I think it's ready for 0.6.4 release, which is
just bugfix release. Although there are a few important issues in the
tracker, I think it's best to release this 0.6.4...can't be delayed forever
:)
And also, because of all the rework on the 0.7 branch, it will probably be
easier to solve some of the issues, there.
Although any opinions are always appreciated.

Another thing...just to boost our egos...although radio trays has been
featured in several places around the net, I finally spotted it in a printed
magazine: http://www.linux-magazine.com/Resources/Current-Issue


Cheers,
Carlos

This looks good!
I guess we don't need "enable_application_indicator_support" at all.

Ed


On Wed, Jun 1, 2011 at 6:00 PM, Carlos Ribeiro <car...@gm...>wrote:
>
>> Hi all,
>>
>> Due to the issues related wich gui to use under different systems, I
>> created a small gui chooser, to allow the user to choose between system tray
>> and app indicator, on the first run.
>> So, now, there's a new configuration option: "gui_engine" that can assume
>> the values: "appindicator", "systray" and "chooser". In the future it might
>> have a "gnomeshell" also.
>>
>> If radio tray can't find the configuration option (in an upgrade
>> situation), then radio tray looks at the default configuration file. This
>> way, the maintainer of the package under a given distro can choose what's
>> the most suitable option. For example, in recent ubuntu versions, it should
>> be "appindicator". In this case, the chooser will never run. However, the
>> official deb package that we provide is a little more generic, so I think
>> the default should be "chooser". In this case, the chooser gui will be run
>> once and the chosen option will be saved in the user configuration file.
>>
>> I think this covers all situations :)
>>
>>
>> Cheers,
>> Carlos Ribeiro
>>
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is
>> safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> Radiotray-devel mailing list
>> Rad...@li...
>> https://lists.sourceforge.net/lists/listinfo/radiotray-devel
>>
>>
>

Hi all,

Due to the issues related wich gui to use under different systems, I created
a small gui chooser, to allow the user to choose between system tray and app
indicator, on the first run.
So, now, there's a new configuration option: "gui_engine" that can assume
the values: "appindicator", "systray" and "chooser". In the future it might
have a "gnomeshell" also.

If radio tray can't find the configuration option (in an upgrade situation),
then radio tray looks at the default configuration file. This way, the
maintainer of the package under a given distro can choose what's the most
suitable option. For example, in recent ubuntu versions, it should be
"appindicator". In this case, the chooser will never run. However, the
official deb package that we provide is a little more generic, so I think
the default should be "chooser". In this case, the chooser gui will be run
once and the chosen option will be saved in the user configuration file.

I think this covers all situations :)


Cheers,
Carlos Ribeiro

Sounds reasonable.

Can we when installing look at the rev being replaced and if needed
flip that value on?


On Mon, May 16, 2011 at 11:41 AM, Carlos Ribeiro
<car...@gm...> wrote:
> Hmm, nice suggestion. I would make just the following change: instead of a
> version number, it may be just a boolean to display or not a dialog.
> However, by adding a command-line parameter to override that boolean option,
> the user can later display it again. That way, the user can safely choose
> whatever option and later change it if it doesn't work.
>
> What do you think ?
>
>
> Cheers,
> Carlos Ribeiro
>
> On Fri, May 13, 2011 at 2:02 AM, Ed Bruck <ed....@gm...> wrote:
>>
>> Would adding a version number to the config help at all?  If it's not
>> there then display a preference dialog on first run. If
>> it's lower than the revision running then also display a preference
>> dialog on first run.
>>
>> Ed
>>
>> On Tue, May 10, 2011 at 2:54 PM, Carlos Ribeiro
>> <car...@gm...> wrote:
>> > Trying the newly created mailing list!
>> >
>> > So, prior to release 0.6.4, here's the status around radio tray and
>> > Ubuntu,
>> > Gnome3, etc
>> >
>> > Ubuntu Unity
>> >
>> > It doesn't work out of the box, because radio tray's default mode is
>> > system
>> > tray and it's not available for radio tray.
>> > Solution for 0.6.4: change the default configuration to app indicator.
>> >
>> > In the case of radio tray update, the previous solution doesn't work
>> > because
>> > the user's configuration file is not overwritten.
>> > The solution is to manually change the user configuration or whitelist
>> > radio
>> > tray in the system tray (guides are available on the net). This has to
>> > be
>> > done manually by the user, so a simple guide needs to be provided (maybe
>> > in
>> > the website, or inside the package itself, etc).
>> >
>> >
>> > Ubuntu Classic
>> >
>> > Works perfectly out of the box with the system tray version. However,
>> > the
>> > default will probably be app indicator because of Unity.
>> >
>> >
>> > Kubuntu 11.04
>> >
>> > As reported and tested, it doesn't work. The reason is still unknown and
>> > it
>> > would be important to investigate how well it works on other kde
>> > systems.
>> >
>> >
>> > Gnome 3
>> >
>> > Untested, but the whole system tray is deprecated. However, for the time
>> > being, I think (but not sure) that the system tray wasn't actually
>> > removed
>> > yet.
>> > Solution: none for now, but research needs to be done to figure out how
>> > to
>> > make a decent gui with the new APIs.
>> >
>> >
>> > Conclusion
>> > Fortunately the new plugin branch already has some gui code separation.
>> > So,
>> > in the future, making a new version for Gnome3 should be possible
>> > alongside
>> > the others.
>> >
>> > Because of all this mess, we desperately need a preferences dialog to
>> > make
>> > this changes easier for the user. If we make a preferences dialog we can
>> > dump the current configuration for system tray/appindicator modes and
>> > make
>> > app indicator the default (this would solve the issue with radio tray
>> > updates in unity). And if the user wants to use the system tray version,
>> > he
>> > can easily change it. Care needs to be taken though: if we select a mode
>> > that is invalid for that system, that change needs to be reverted
>> > somehow.
>> > It would be better if we could detect if the system tray is available,
>> > but
>> > I'm not sure if that's possible.
>> >
>> >
>> > Any other ideas ?
>> >
>> > Cheers,
>> > Carlos Ribeiro
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Achieve unprecedented app performance and reliability
>> > What every C/C++ and Fortran developer should know.
>> > Learn how Intel has extended the reach of its next-generation tools
>> > to help boost performance applications - inlcuding clusters.
>> > http://p.sf.net/sfu/intel-dev2devmay
>> > _______________________________________________
>> > Radiotray-devel mailing list
>> > Rad...@li...
>> > https://lists.sourceforge.net/lists/listinfo/radiotray-devel
>> >
>> >
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Radiotray-devel mailing list
> Rad...@li...
> https://lists.sourceforge.net/lists/listinfo/radiotray-devel
>
>

Hmm, nice suggestion. I would make just the following change: instead of a
version number, it may be just a boolean to display or not a dialog.
However, by adding a command-line parameter to override that boolean option,
the user can later display it again. That way, the user can safely choose
whatever option and later change it if it doesn't work.

What do you think ?


Cheers,
Carlos Ribeiro

On Fri, May 13, 2011 at 2:02 AM, Ed Bruck <ed....@gm...> wrote:

> Would adding a version number to the config help at all?  If it's not
> there then display a preference dialog on first run. If
> it's lower than the revision running then also display a preference
> dialog on first run.
>
> Ed
>
> On Tue, May 10, 2011 at 2:54 PM, Carlos Ribeiro
> <car...@gm...> wrote:
> > Trying the newly created mailing list!
> >
> > So, prior to release 0.6.4, here's the status around radio tray and
> Ubuntu,
> > Gnome3, etc
> >
> > Ubuntu Unity
> >
> > It doesn't work out of the box, because radio tray's default mode is
> system
> > tray and it's not available for radio tray.
> > Solution for 0.6.4: change the default configuration to app indicator.
> >
> > In the case of radio tray update, the previous solution doesn't work
> because
> > the user's configuration file is not overwritten.
> > The solution is to manually change the user configuration or whitelist
> radio
> > tray in the system tray (guides are available on the net). This has to be
> > done manually by the user, so a simple guide needs to be provided (maybe
> in
> > the website, or inside the package itself, etc).
> >
> >
> > Ubuntu Classic
> >
> > Works perfectly out of the box with the system tray version. However, the
> > default will probably be app indicator because of Unity.
> >
> >
> > Kubuntu 11.04
> >
> > As reported and tested, it doesn't work. The reason is still unknown and
> it
> > would be important to investigate how well it works on other kde systems.
> >
> >
> > Gnome 3
> >
> > Untested, but the whole system tray is deprecated. However, for the time
> > being, I think (but not sure) that the system tray wasn't actually
> removed
> > yet.
> > Solution: none for now, but research needs to be done to figure out how
> to
> > make a decent gui with the new APIs.
> >
> >
> > Conclusion
> > Fortunately the new plugin branch already has some gui code separation.
> So,
> > in the future, making a new version for Gnome3 should be possible
> alongside
> > the others.
> >
> > Because of all this mess, we desperately need a preferences dialog to
> make
> > this changes easier for the user. If we make a preferences dialog we can
> > dump the current configuration for system tray/appindicator modes and
> make
> > app indicator the default (this would solve the issue with radio tray
> > updates in unity). And if the user wants to use the system tray version,
> he
> > can easily change it. Care needs to be taken though: if we select a mode
> > that is invalid for that system, that change needs to be reverted
> somehow.
> > It would be better if we could detect if the system tray is available,
> but
> > I'm not sure if that's possible.
> >
> >
> > Any other ideas ?
> >
> > Cheers,
> > Carlos Ribeiro
> >
> >
> ------------------------------------------------------------------------------
> > Achieve unprecedented app performance and reliability
> > What every C/C++ and Fortran developer should know.
> > Learn how Intel has extended the reach of its next-generation tools
> > to help boost performance applications - inlcuding clusters.
> > http://p.sf.net/sfu/intel-dev2devmay
> > _______________________________________________
> > Radiotray-devel mailing list
> > Rad...@li...
> > https://lists.sourceforge.net/lists/listinfo/radiotray-devel
> >
> >
>

Would adding a version number to the config help at all?  If it's not
there then display a preference dialog on first run. If
it's lower than the revision running then also display a preference
dialog on first run.

Ed

On Tue, May 10, 2011 at 2:54 PM, Carlos Ribeiro
<car...@gm...> wrote:
> Trying the newly created mailing list!
>
> So, prior to release 0.6.4, here's the status around radio tray and Ubuntu,
> Gnome3, etc
>
> Ubuntu Unity
>
> It doesn't work out of the box, because radio tray's default mode is system
> tray and it's not available for radio tray.
> Solution for 0.6.4: change the default configuration to app indicator.
>
> In the case of radio tray update, the previous solution doesn't work because
> the user's configuration file is not overwritten.
> The solution is to manually change the user configuration or whitelist radio
> tray in the system tray (guides are available on the net). This has to be
> done manually by the user, so a simple guide needs to be provided (maybe in
> the website, or inside the package itself, etc).
>
>
> Ubuntu Classic
>
> Works perfectly out of the box with the system tray version. However, the
> default will probably be app indicator because of Unity.
>
>
> Kubuntu 11.04
>
> As reported and tested, it doesn't work. The reason is still unknown and it
> would be important to investigate how well it works on other kde systems.
>
>
> Gnome 3
>
> Untested, but the whole system tray is deprecated. However, for the time
> being, I think (but not sure) that the system tray wasn't actually removed
> yet.
> Solution: none for now, but research needs to be done to figure out how to
> make a decent gui with the new APIs.
>
>
> Conclusion
> Fortunately the new plugin branch already has some gui code separation. So,
> in the future, making a new version for Gnome3 should be possible alongside
> the others.
>
> Because of all this mess, we desperately need a preferences dialog to make
> this changes easier for the user. If we make a preferences dialog we can
> dump the current configuration for system tray/appindicator modes and make
> app indicator the default (this would solve the issue with radio tray
> updates in unity). And if the user wants to use the system tray version, he
> can easily change it. Care needs to be taken though: if we select a mode
> that is invalid for that system, that change needs to be reverted somehow.
> It would be better if we could detect if the system tray is available, but
> I'm not sure if that's possible.
>
>
> Any other ideas ?
>
> Cheers,
> Carlos Ribeiro
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Radiotray-devel mailing list
> Rad...@li...
> https://lists.sourceforge.net/lists/listinfo/radiotray-devel
>
>

Trying the newly created mailing list!

So, prior to release 0.6.4, here's the status around radio tray and Ubuntu,
Gnome3, etc

*Ubuntu Unity*

It doesn't work out of the box, because radio tray's default mode is system
tray and it's not available for radio tray.
Solution for 0.6.4: change the default configuration to app indicator.

In the case of radio tray update, the previous solution doesn't work because
the user's configuration file is not overwritten.
The solution is to manually change the user configuration or whitelist radio
tray in the system tray (guides are available on the net). This has to be
done manually by the user, so a simple guide needs to be provided (maybe in
the website, or inside the package itself, etc).


*Ubuntu Classic*

Works perfectly out of the box with the system tray version. However, the
default will probably be app indicator because of Unity.


*Kubuntu 11.04*

As reported and tested, it doesn't work. The reason is still unknown and it
would be important to investigate how well it works on other kde systems.


*Gnome 3*

Untested, but the whole system tray is deprecated. However, for the time
being, I think (but not sure) that the system tray wasn't actually removed
yet.
Solution: none for now, but research needs to be done to figure out how to
make a decent gui with the new APIs.


*Conclusion*
Fortunately the new plugin branch already has some gui code separation. So,
in the future, making a new version for Gnome3 should be possible alongside
the others.

Because of all this mess, we desperately need a preferences dialog to make
this changes easier for the user. If we make a preferences dialog we can
dump the current configuration for system tray/appindicator modes and make
app indicator the default (this would solve the issue with radio tray
updates in unity). And if the user wants to use the system tray version, he
can easily change it. Care needs to be taken though: if we select a mode
that is invalid for that system, that change needs to be reverted somehow.
It would be better if we could detect if the system tray is available, but
I'm not sure if that's possible.


Any other ideas ?

Cheers,
Carlos Ribeiro

Test Message

This is a test