notification area

Moderator: Moderator

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

notification area

Postby castorinop » Thu May 24, 2007 12:11 pm

the idea is that the user can be see multiple infromation in determinate area of screen, maybe in the corner bottom, right. (all modules)

for example
loop with 5 seconds of interval between items
  • track number of playlist (18/234) when music is play.
  • random mode (img)
  • repeat and shutdown mode (img)
  • date & time (posible plugin)
  • wheater (posible plugin with img and temp)
  • other plugin
Last edited by castorinop on Thu May 24, 2007 1:58 pm, edited 3 times in total.

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Thu May 24, 2007 12:23 pm

Nice idea!

This corresponds to this one:
http://mms.kicks-ass.org/flyspray/?do=details&task_id=158

P.S. For weather I have my "windows"-plugin :P
Lg
Roman

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Fri May 25, 2007 7:11 am

Btw. ... do you create a feature-request for it?
Lg

Roman

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Sat May 26, 2007 4:18 pm

Uatschitchun wrote:Btw. ... do you create a feature-request for it?

yes http://bugs.mymediasystem.org/?do=details&task_id=189

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Tue Sep 04, 2007 6:07 pm

this is patch for 1.0.9
notify-area.patch
notify-area_lang-es.patch

i wait your comments

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Tue Sep 04, 2007 9:23 pm

Interesting concept. Sadly it's against 1.0.9 again :)

Not sure how this idea will fit into 1.1.0. Probably as part of the core functionality. One would probably at least want to be able to disable the feature.

Small review of the patch:

1) + strMsg = gettext(dayOfWeek(date->getDayOfWeek()).c_str());

I don't think that works. One needs do add gettext around each individual string, even if the intend is clear from the eye of the programmer:

+string NotifyDateTime::dayOfWeek(int date)
+{
+ string buff;
+ switch (date) {
+ case 0: buff = "sunday"; break;
+ case 1: buff = "monday"; break;
+ case 2: buff = "tuesday"; break;
+ case 3: buff = "wednesday"; break;
+ case 4: buff = "thursday"; break;
+ case 5: buff = "friday"; break;
+ case 6: buff = "saturday"; break;
+ }
+ return buff;
+}

2) These variable aren't scoped and I'm generally against #defines. It's one of the legacies of C that should just be forgotten :)

+#define NOTIFY_AREA_W 144
+#define NOTIFY_AREA_H 76
+
+#define NOTIFY_AREA_X (conf->p_v_res() - NOTIFY_AREA_W)
+#define NOTIFY_AREA_Y (conf->p_h_res() - NOTIFY_AREA_H)
+#define NOTIFY_AREA_W_2 (conf->p_v_res() - NOTIFY_AREA_W/2)
+#define NOTIFY_AREA_H_2 (conf->p_h_res() - NOTIFY_AREA_H/2)
+#define NOTIFY_AREA_W_4 (conf->p_v_res() - NOTIFY_AREA_W/4)
+#define NOTIFY_AREA_H_4 (conf->p_h_res() - NOTIFY_AREA_H/4)

I'm actually somewhat puzzled that it even works :) Anyway I would define the area_width and area_height as static const variables on the notify area class and then just write the (conf->p_v_res() - NOTIFY_AREA_W/2) instead of NOTIFY_AREA_W_2. It's much more clear what's going on then. No magic :)

Other than that it looks really good.

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Tue Sep 04, 2007 10:59 pm

arj wrote:Interesting concept. Sadly it's against 1.0.9 again :)

:) sorry, i'm using 1.0.9 for my media center.
arj wrote:Not sure how this idea will fit into 1.1.0. Probably as part of the core functionality. One would probably at least want to be able to disable the feature.
"

:roll:
arj wrote:Small review of the patch:

1) + strMsg = gettext(dayOfWeek(date->getDayOfWeek()).c_str());

I don't think that works. One needs do add gettext around each individual string, even if the intend is clear from the eye of the programmer:

+string NotifyDateTime::dayOfWeek(int date)
+{
+ string buff;
+ switch (date) {
+ case 0: buff = "sunday"; break;
+ case 1: buff = "monday"; break;
+ case 2: buff = "tuesday"; break;
+ case 3: buff = "wednesday"; break;
+ case 4: buff = "thursday"; break;
+ case 5: buff = "friday"; break;
+ case 6: buff = "saturday"; break;
+ }
+ return buff;
+}

date->getDayOfWeek() return value beetwen 0 to 6 indiicate day of week.
dayOfWeek return the string of the day (0 to 6).
and gettext for localization.

that you advise to improve this?

arj wrote:2) These variable aren't scoped and I'm generally against #defines. It's one of the legacies of C that should just be forgotten :)

+#define NOTIFY_AREA_W 144
+#define NOTIFY_AREA_H 76
+
+#define NOTIFY_AREA_X (conf->p_v_res() - NOTIFY_AREA_W)
+#define NOTIFY_AREA_Y (conf->p_h_res() - NOTIFY_AREA_H)
+#define NOTIFY_AREA_W_2 (conf->p_v_res() - NOTIFY_AREA_W/2)
+#define NOTIFY_AREA_H_2 (conf->p_h_res() - NOTIFY_AREA_H/2)
+#define NOTIFY_AREA_W_4 (conf->p_v_res() - NOTIFY_AREA_W/4)
+#define NOTIFY_AREA_H_4 (conf->p_h_res() - NOTIFY_AREA_H/4)

I'm actually somewhat puzzled that it even works :) Anyway I would define the area_width and area_height as static const variables on the notify area class and then just write the (conf->p_v_res() - NOTIFY_AREA_W/2) instead of NOTIFY_AREA_W_2. It's much more clear what's going on then. No magic :)

Other than that it looks really good.


good suggest. i'm working on it.

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Wed Sep 05, 2007 8:35 am

castorinop wrote:1) + strMsg = gettext(dayOfWeek(date->getDayOfWeek()).c_str());

I don't think that works. One needs do add gettext around each individual string, even if the intend is clear from the eye of the programmer:

+string NotifyDateTime::dayOfWeek(int date)
+{
+ string buff;
+ switch (date) {
+ case 0: buff = "sunday"; break;
+ case 1: buff = "monday"; break;
+ case 2: buff = "tuesday"; break;
+ case 3: buff = "wednesday"; break;
+ case 4: buff = "thursday"; break;
+ case 5: buff = "friday"; break;
+ case 6: buff = "saturday"; break;
+ }
+ return buff;
+}

date->getDayOfWeek() return value beetwen 0 to 6 indiicate day of week.
dayOfWeek return the string of the day (0 to 6).
and gettext for localization.

that you advise to improve this?


1) + strMsg = dayOfWeek(date->getDayOfWeek()).c_str();

string NotifyDateTime::dayOfWeek(int date)
{
string buff;
switch (date) {
case 0: buff = gettext("sunday"); break;
case 1: buff = gettext("monday"); break;
case 2: buff = gettext("tuesday"); break;
case 3: buff = gettext("wednesday"); break;
case 4: buff = gettext("thursday"); break;
case 5: buff = gettext("friday"); break;
case 6: buff = gettext("saturday"); break;
}
return buff;
}

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Thu Sep 06, 2007 7:35 am

Hi there

I haven't tested these patches until now, but made up my mind on them ;)

Shouldn't we go a more modular/flexible way with the 'notification-area'?
If it should go into 1.1.0, we need to make free (as much as possible) from hardcoded features! So making the 'n-a' flexible in a way that the user is able to define what he wants to see could be a first step.

More important and also more interesting could be the possibility to open up the 'n-a' to plugins (day-of-week-plugin, weather-plugin, etc.) and/or to simply make plugins able to communicate to the user using the 'n-a' ?!
With this we are not restricted to what is hardcoded into MMS, but plugins are able to provide information (if the user wants them to).

So providing an API to the 'n-a' would be a good step forward, wouldn't it?
Maybe having a place where plugins could register their need/ability of using the 'n-a' and let the user decide, what infos he likes to see and what plugins he wants to put infos in there?

MMS should only provide the API, not more not less ...
plugins like 'audio' could make use of this API to show random-mode, repeat, etc. ... a plugin like 'movie' could use the 'n-a' for to display an icon related to the file-type (avi, mpeg, etc.) while browsing ... the screensaver (if enhanced with an API, too) could display time-of-day, day-of-week, weather, etc. ... a whole lot would become be possible ...

What do you think?
Isn't it time to say goodbye to 1.0.9-way of adding features?
Lg

Roman

User avatar
acmelabs
Overlord
Posts: 2365
Joined: Mon Feb 20, 2006 9:18 pm
Location: Germany
Contact:

Postby acmelabs » Thu Sep 06, 2007 8:36 am

Uatschitchun wrote:Hi there

I haven't tested these patches until now, but made up my mind on them ;)

Shouldn't we go a more modular/flexible way with the 'notification-area'?
If it should go into 1.1.0, we need to make free (as much as possible) from hardcoded features! So making the 'n-a' flexible in a way that the user is able to define what he wants to see could be a first step.

More important and also more interesting could be the possibility to open up the 'n-a' to plugins (day-of-week-plugin, weather-plugin, etc.) and/or to simply make plugins able to communicate to the user using the 'n-a' ?!
With this we are not restricted to what is hardcoded into MMS, but plugins are able to provide information (if the user wants them to).

So providing an API to the 'n-a' would be a good step forward, wouldn't it?
Maybe having a place where plugins could register their need/ability of using the 'n-a' and let the user decide, what infos he likes to see and what plugins he wants to put infos in there?

MMS should only provide the API, not more not less ...
plugins like 'audio' could make use of this API to show random-mode, repeat, etc. ... a plugin like 'movie' could use the 'n-a' for to display an icon related to the file-type (avi, mpeg, etc.) while browsing ... the screensaver (if enhanced with an API, too) could display time-of-day, day-of-week, weather, etc. ... a whole lot would become be possible ...

What do you think?
Isn't it time to say goodbye to 1.0.9-way of adding features?

and here are my 2 cent:
    wouldn't it be great to send messages to the 'n-a' via network? I mean, having a network support in MMS wouldn't be too bad, would it?

Does this reminds anybody of VDRs network support à la 'telnet my-vdr-box-name-here 2001'? ;-)

I know it's a core breach, that's why I'm thinking of MMS 1.2.x.

Many interesting things would be possible with this kind of ability. Such things like: mmsadmin, remote messaging or mms browser control in general (e.g. on PDAs w/o VNC).

Regards,
Andreas

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Thu Sep 06, 2007 1:33 pm

Uatschitchun wrote:Isn't it time to say goodbye to 1.0.9-way of adding features?


yes, i promess that my next's patches will be for 1.1.0 but... i'm working on weather module :roll:

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Thu Sep 06, 2007 1:54 pm

Uatschitchun wrote:Shouldn't we go a more modular/flexible way with the 'notification-area'?


is flexible, the architecture is similar to updater. the modules register that methods will be called by nArea loop. May be should improve the way to render, and don't let the method to decide the screen position, just the position inside of the area.

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Thu Sep 06, 2007 5:23 pm

castorinop wrote:
Uatschitchun wrote:Isn't it time to say goodbye to 1.0.9-way of adding features?


yes, i promess that my next's patches will be for 1.1.0 but... i'm working on weather module :roll:

It wasn't meant like that, don't get me wrong!
More in that way:
http://mms.kicks-ass.org/forum/viewtopic.php?t=893
Lg

Roman

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Thu Sep 06, 2007 9:09 pm

castorinop wrote:
Uatschitchun wrote:Isn't it time to say goodbye to 1.0.9-way of adding features?


yes, i promess that my next's patches will be for 1.1.0 but... i'm working on weather module :roll:


Cool. I'm sure it will make a lot of users happy, it's one of the most request missing features!


Return to “feature requests”

Who is online

Users browsing this forum: No registered users and 2 guests