@jv2007
If you want to use @font-face, you can use like this;
@font-face {
font-family: 'korean';
src: url('./notosans.ttf') format('truetype');
unicode-range: U+AC00-FFDD;
}
@font-face {
font-family: 'english';
src: url('./opensanscondensed.ttf') format('truetype');
}
div.test {
font-family: 'korean', 'english';
}
@jv2007
But, more simple way is; just use this;
body {
font-family: 'Open Sans Condensed', 'Noto Sans KR';
}
Open Sans Condensed font doesn’t have any Korean characters, so when the renderer meet Korean chars, the second fallback Noto Sans KR would be applied instead of Open Sans Condensed.
@jv2007
Option 1 is almost right, but each font-face needs to have a different name.
Option 2 or 3 seems something related to lang attribute. If your content has explicit lang attribute on the element, it might be work, but, as far as I understand, that might not be your thing.
@BKeyport
MMM-NotificationTrigger for that purpose.
@Spinster said in Show calendar based on IP Address accessed:
Modified the calendars to suite mine. I could see even if there is no calendar defined for a particular ip. Please advice
in the calendar config, I added clientMap.
{
module: "calendar",
header: "US Holidays",
position: "top_left",
config: {
clientMap: {
"192.168.178.63": [ "cal1", "cal2", "cal3" ],
"192.168.178.22": [ "cal3", "cal4", "cal5" ]
},
calendars: [
{
url: "...",
name: "cal1",
},
...
@sdetweil
Still I can’t catch you.
[2024-05-07 15:03:33.741] [LOG] Use existing calendarfetcher for url: https://ics.calendarlabs.com/76/mm3137/US_Holidays.ics
The log shows, duplicated URL would be integrated into existing fetcher, So unlike your words, 3 clients doesn’t make 3 duplicated wasted fetcher.
If clientA needs cal1, cal2, cal3 and clientB needs cal1, cal4, cal5. In this case server should fetch 5 calendars anyway. User may need cal1 ~ cal5 even on 1 screen or 2 screens, ther server’s burden would be the same.
The only aspect that could be considered a waste is the transmission of unusing event data for cal4 and cal5 to clientA, but unless it’s a performance issue with the data parsing algorithm, simply having large data size being transmitted isn’t particularly problematic. Moreover, since the data is dropped in my code as soon as the notification is received, it can’t be deemed a significant memory issue. If the data size itself becomes problematic, it implies there’s already a problem with the original calendar module using cal1, cal2, cal3, cal4, and cal5.
Too skeptic.
@sdetweil said in Show calendar based on IP Address accessed:
@MMRIZE said in Show calendar based on IP Address accessed:
(You don’t have to modify the original source code for future-proof.)
BUT you are fetching cal for system not going to use it… SOME cals are 1000’s of entries especially old
that have to be processed… this is a bad waste of resources…and this exposes a cal problem, as if u fetch http://xyz on client 1 and client 2 and client 3, we fetch it 3 times. also bad
this could also lead to different clients showing different data between fetchIntervals…
Well, if that is the issue, we need a new “calendar” module that can ignore duplicated feed on addCalendar.
Regardless of my code, the original calendar module will fetch a same feed multiply on multi clients. It’s MM’s limitation.
@sdetweil said in Show calendar based on IP Address accessed:
BUT you are fetching cal for system not going to use it… SOME cals are 1000’s of entries especially old
that have to be processed… this is a bad waste of resources…
I Can’t understand your point.
My code is just small injection that does filtering out calendars by condition on socketNotificationReceived. No additional fetching is needed.
@Spinster
With getip of @sdetweil and MMM-ModuleMonkeyPatch, I did it. (You don’t have to modify the original source code for future-proof.)
Example.
Server is running on 192.168.178.63 and I run 2 clients on 192.168.178.22 and 192.168.178.63.
Both 2 clients can show different set of calendars.
{
module: "MMM-ModuleMonkeyPatch",
config: {
patches: [
{
module: "calendar",
method: "socketNotificationReceived",
patch: async function (original, args) {
const [ notification, payload ] = args
if (notification === "CALENDAR_EVENTS") {
const calendarName = this.config.calendars.find((cal) => cal.url === payload?.url)?.name
const r = await fetch('http://192.168.178.63:8080/modules/getip')
const ip = JSON.parse(await r.text())?.[ 'address' ] ?? null
if (!this.config.clientMap?.[ ip ]?.includes(calendarName)) {
return original(notification, { ...payload, events: [] })
}
}
return original(notification, payload)
}
}
]
}
},
{
module: "getip",
},
{
module: "calendar",
header: "US Holidays",
position: "top_left",
config: {
clientMap: {
"192.168.178.63": [ "cal1", "cal2", "cal3" ],
"192.168.178.22": ["cal3", "cal4", "cal5"]
},
calendars: [
{
url: "...",
name: "cal1",
},
{
url: "...",
name: "cal2",
},
{
url: "...",
name: "cal3",
},
{
url: "...",
name: "cal4",
},
{
url: "...",
name: "cal5",
}
]
}
},
TO Improve
Whenever notification CALENDAR_EVENTS coming, getip is called. After first execution, to store IP on the localStorage or cookie would be better.
@Spinster
By the way, which client are you using? Electron? Or Browser?
@Old_Death I updated yesterday. Did you check it?
@sdetweil
Yes. I thought a small module with node_helper that could return clients’ ip as a result of REST api call from calendar module.
@Spinster
Ah I suddenly remember that getting Internal IP with only JavaScript on client browseris hard.
Hmmm another approach might be needed.
@Spinster
I’m out of my test PC, so I can’t show atm. (Maybe tomorrow possible, if you couldn’t success until that time)
You can add custom config attribute map-like object calendarMap in your config.js
module: "calendar",
position: "top_left",
config: {
calendarMap: {
"192.168.178.100": ["calendar1", "calendar2"],
"192.168.178.101": ["calebdar1", "calendar3"],
},
calendars: [
{
url: " … ",
name: "calendar1",
},
…
In calendar.js around line 176, when CALENDAR_EVENTS notification coming, you can filter the payload(array of events) of that notification by checking calendarName of each event is matched to this.config.calendarMap.
Sorry I can’t show the real code now. Maybe some hours later I may be able to. Anyway concept would be like this.
@Spinster
Depending on the environment and which modules you want to display on the screen, it may vary, but… If you don’t have many clients (less than 10) and your server has sufficient capacity, it might be better to provide each client with a dedicated server instance with a different port number. For example, Client 1 - Port 8081, Client 2 - Port 8082, … If there are 10 clients, run 10 MM servers.
You just need to setup config.js of each client-server pair for your purpose.
There’s no need to modify the source code, and you also don’t need to allocate fixed IP addresses for each client through router settings or WLAN settings of clients. Usually, in home or office environments, DHCP is common, so this would be a simpler approach.
@Old_Death
I found out what was wrong. I made some mistakes in my previous updates, and there is still a missing one. I’ll fix it and update it soon.
@Old_Death
Share with me your config (eouia0819@gmail.com)
@Dennys1
Are you using MMM-GroveGesture?
@Old_Death
Sorry, there was still another hidden formatting-twice issue. (in onlyEventDays. I didn’t check that part on the previous update.)
I fixed it now.
