Greek (Extended).Keymap – Greek Polytonic keyboard

[greekboy]

Haiku does not support Greek Polytonic for my greek language, but Windows, Linux and MacOS can. A long time ago I started my own project for Haiku in order to support Greek Polytonic keyboard. My source code increased the 5 dead-keys up to 32 dead-keys and also each dead key array can contain up to 19 pairs of dead key characters. Of course it does not break compatibility.

The project is finished and I have attached my patches. If you accept my patches, please also close the other ticket:

https://dev.haiku-os.org/ticket/2098#

Here is the video showing the possibilities.

​http://www.youtube.com/watch?v=rICUMM1gQls

[korli]

Hi Hristos,

thanks for the patchs. They look clean and fine though git format-patch is preferred.

Unfortunately changing the struct keymap (in InterfaceDefs.h.patch) breaks binary compatibility. I have yet no idea on how to improve the situation related to the number of dead-keys.

[greekboy]

I' m not understand. What do you mean, break binary compatibility?

My source code works very well.

[anevilyak]

Replying to greekboy:

I' m not understand. What do you mean, break binary compatibility?

The keymap structure is public. Consequently, changing its size will break existing executables that make use of it (and were compiled against the previous version). This is something we try to avoid.

[greekboy]

Replying to anevilyak:

Replying to greekboy:

I' m not understand. What do you mean, break binary compatibility?

The keymap structure is public. Consequently, changing its size will break existing executables that make use of it (and were compiled against the previous version). This is something we try to avoid.

Do you talk about executables applications? See in my video. Time: 16:07 - 19:04.

[axeld]

Thanks a lot for your patches, but please use git format-patch in the future.

About the binary compatibility problem: applications will not crash by your changes (since the only way to retrieve a key_map structure is via get_key_map(), and that one is safe in this regard).

However, even if we change the version of that structure, old applications using the table will use it incorrectly, as the location of things changed. You could fix this by not extending the existing arrays, but rather by adding new ones to the end of the structure. Unfortunately, this would make pretty much all changes rather messy. I also believe (but haven't checked) that you break the on-disk format of our binary keymap files -- this would not be acceptable at all.

Since we can determine whether an application has been linked against Haiku libraries, or BeOS libraries, we could also provide the new structure only for new applications. This would require a mechanism to convert the structures for old apps, though.

Do you understand what I'm trying to explain here, Hristos?

BTW, we do not add authors to the header files; it wasn't missing by accident. And if you actually have to add such a list, please fill it from its log history as a courtesy to the other authors.

[greekboy]

I understand.

I have no problem if you erase my name. Just I wanted to help you.

[greekboy]

Replying to axeld:

I also believe (but haven't checked) that you break the on-disk format of our binary keymap files -- this would not be acceptable at all.

See in my video. Time: 16:42 - 19:04.

[axeld]

Replying to greekboy:

I understand.

I'm not really sure about that, actually.

I have no problem if you erase my name. Just I wanted to help you.

I guess you misunderstood: the public headers don't have an author list (InterfaceDefs.h), everything else has.

I also believe (but haven't checked) that you break the on-disk format of our binary keymap files -- this would not be acceptable at all.

See in my video. Time: 16:42 - 19:04.

First of all, it's unreasonable to have to watch a video for this. Please just answer in plain text instead. Also, that video doesn't show that. While the text format looks similar, the binary format may not. Can't you just answer for real, and show me why it does not break the binary format compatibility?

We'd really like to include this functionality into Haiku, and appreciate your effort. However, in the current form, we cannot accept your patch, unfortunately.

[greekboy]

Replying to axeld:

First of all, it's unreasonable to have to watch a video for this. Please just answer in plain text instead. Also, that video doesn't show that. While the text format looks similar, the binary format may not. Can't you just answer for real, and show me why it does not break the binary format compatibility?

I can't answer for binary format compatibility.

You could fix this by not extending the existing arrays, but rather by adding new ones to the end of the structure.

You mean like this?

int32 acute_dead_key[38]; int32 grave_dead_key[38]; int32 circumflex_dead_key[38]; int32 dieresis_dead_key[38]; int32 tilde_dead_key[38]; int32 acutesmooth_dead_key[38]; int32 acuterough_dead_key[38]; int32 acutediaeresis_dead_key[38]; int32 acutesubscript_dead_key[38]; int32 acutesmoothsubscript_dead_key[38]; int32 acuteroughsubscript_dead_key[38]; int32 gravesmooth_dead_key[38]; int32 graverough_dead_key[38]; int32 gravediaeresis_dead_key[38]; int32 gravesubscript_dead_key[38]; int32 gravesmoothsubscript_dead_key[38]; int32 graveroughsubscript_dead_key[38]; int32 smooth_dead_key[38]; int32 smoothcircumflex_dead_key[38]; int32 smoothsubscript_dead_key[38]; int32 smoothcircumflexsubscript_dead_key[38]; int32 rough_dead_key[38]; int32 roughcircumflex_dead_key[38]; int32 roughsubscript_dead_key[38]; int32 roughcircumflexsubscript_dead_key[38]; int32 circumflexdiaeresis_dead_key[38]; int32 circumflexsubscript_dead_key[38]; int32 diaeresisaccent_dead_key[38]; int32 accent_dead_key[38]; int32 macron_dead_key[38]; int32 breve_dead_key[38]; int32 subscript_dead_key[38];

Also I' ll use git format-patch.

Give me a few days.

[greekboy]

The files are in git format-patch. The source code is the same, its structure shouldn’t change (the sequence of the dead keys) and also don’t rename the dead-keys, because the patches won’t function properly. Also I deleted my name from the file header InterfaceDefs.h. Try it and if you want it, you can use it.

Take care. The Lord bless you.

[X512]

Hardcoding Greek language-specific fields is not a good idea. It's better to extend key_map in more general way such as unlimited number of dead keys and affected symbols.

[greekboy]

My source code is 100% compatible with Greek Polytonic System in Windows.

​http://en.wikipedia.org/wiki/Greek_diacritics

​http://www.logos.com/media/support/logos_bible_software_keyboard_layout_greek_polytonic.pdf

​http://www.unicode.org/charts/PDF/U1F00.pdf

​http://www.unicode.org/charts/PDF/U0370.pdf

​http://www.google.com/url?sa=t&rct=j&q=greek%20polytonic%20microsoft&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F2%2F5%2F4%2F2543a817-a8c4-4c63-a46a-f04a82bf623e%2FThe%2520Greek%2520Polytonic%2520System.doc&ei=Y5K7UduRN8L3O_6lgBA&usg=AFQjCNFNPerhkuffSX47w2qyFKk_2e7JOg&bvm=bv.47883778,d.ZWU

[X512]

Replying to greekboy:

My source code is 100% compatible with Greek Polytonic System in Windows.

Nobody says that it is not. Haiku does not try to be Windows-comparible in any way. Your solution is specific for Greek language and nothing more. Language-specific info should be stored in keymap file and not hardcoded in key_map structure.

Possible solution can be:

struct key_map_ex {
	uint32	version;
	uint32	caps_key;
	uint32	scroll_key;
	uint32	num_key;
	uint32	left_shift_key;
	uint32	right_shift_key;
	uint32	left_command_key;
	uint32	right_command_key;
	uint32	left_control_key;
	uint32	right_control_key;
	uint32	left_option_key;
	uint32	right_option_key;
	uint32	menu_key;
	uint32	lock_settings;
	int32	control_map[128];
	int32	option_caps_shift_map[128];
	int32	option_caps_map[128];
	int32	option_shift_map[128];
	int32	option_map[128];
	int32	caps_shift_map[128];
	int32	caps_map[128];
	int32	shift_map[128];
	int32	normal_map[128];
	uint32	dead_key_count;
	struct {
		int32 chars;
		uint32 tables;
	} dead_keys[1];
};

void	get_key_map_ex(uint32 version, key_map_ex** _map, char** _keyBuffer);

This extension is universal and don't break binary compatability. Also it add ability of future extentions.

Another solution can be adding dead_key_count and dead_keys to the end of current key_map structure and don't use "ex" versions. dead_key_count will be set to 0 if predefined dead keys is enougth.

[pulkomandy]

I have marked the patches as obsolete for the reasons mentionned above. If I understand things correctly, this is not needed to type "modern" greek. I would suggest writing a dedicated input method rather than extending the keymap system in such non-compatible way.

[pulkomandy]

You can now use ​http://haiku.healynet.org/xdk.html to get custom keymaps. Relevant discussion: ​https://discuss.haiku-os.org/t/keymap-and-new-dead-keys/4454