quote:
Originally posted by Kian
Easy tiggr... i am just trying to mess around with the idea... nothing else -
grrrrrawnn.... I'm easy though
quote:
Originally posted by Kian
I dont think you get my point. My point is that if two menus are placed on eachother like layers and only one of them is visible the collision-checker is still seeing collisions even though it isnt 'real' collisions.
It sure is in the way Plus! is programmed at the moment; As long as an option isn't ticked/unticked when you press an ampersand, but rather cycles thru the availbe options, then it is a collision, no matter how you try to interpret it.
In fact, the way it is programmed at the moment in Plus! can cause unwanted effects as you actually can change those 'hidden' controls by accident.
quote:
Originally posted by Kian
The difficult thing is that the program should know which menu/layer is visible.
No. The program doesn't need to know which layer is visible or what not. That is, it should depend on the special 'index' file, not on ini topics, not on visible layers or whatever else.
quote:
Originally posted by Kian
But still i claim that it dosnt matter! If two equal shortcuts are found - one in the hidden layer and one in the visible layer - it isnt a collision to you and me but it is to the program.
For me it sure is a collision as that is exactly what a collision is. An ampersand collides (with whatever) as long as it does not perform its duty. And that duty is ticking/unticking the control it is meant for.
It doesn't matter if that happens because of hidden controls or even another 3rd party which prevents the use of a certain shortcut key so to speak.
quote:
Originally posted by Kian
But would you care about if the shortcut is changed to fit the program? I wouldnt care at all as long as the shortcut works and dosnt coalate (how do you 'bend' collision'?)
collide
A collision is exactly that, the same ampersand used on different controls in the same focus. If it does that, the ampersand does NOT work. It doesn't matter if that other control is hidden or whatever, if the visible control is not ticked/unticked you have a collision.
quote:
Originally posted by Kian
quote:
I hope you didn't just suggested to also make the program automatically fix collisions
I am aware of this: the collision-program fixes issues thats already okay... but as I said before: it is a typical OOP-problem - its almost impossible to get a computer to think the way we do and therefor stuff like this has to be done - it might seems like a awkward way but it is necessary and as long as the program dosnt mess up the ampersands its okay from my point of niew
Some collisions might be intended though.
And a program should never auto-fix ampersand collisions as a program (like you rightfully put it) can't think as a human beeing.
Ampersands are (at least should be) placed with some logic behind it, not simply because some letters aren't available anymore.
This has been discussed also in the past though...
quote:
Originally posted by Kian
And the last part of your post: I know it would mean that the structure should be completely re-designed... and so should Messenger Plus. Thats why i said that I was sad about that it wasnt done from the beginning.
That is not the issue. It can NOT be done, even when done from the start...
quote:
Originally posted by Kian
I see that the amount of the language-file will expand... i dont know - still i think that certain sections could be organized as they are today... like the standard-button-issue - no need to translate 50 'Cancel'-buttons.
Not all cancel buttons are translated as "cancel" in some languages. In some languages it is more logical to translate it as "close" or "quit" or whatever so to speak depending on what dialog they're used on.
The reason why there are so many OK, Cancel, etc buttons is because those are different buttons on different dialogs all together.
In fact, this is a whole other issue than what I meant with duplicated stuff...
What you just describe is:
You have two totally different dialog windows with each an OK button. You could make the translation engine so that there is only 1 translation for the both of them. But this seriously decreases the the freedom of the translators. For a think like the OK button, this seems a bit useless, but consider controls with the same initial English translation "Contact List Viewer" on totally different dialog windows. It is quiet possible that on one dialog the translated text will fit, but on the other dialog it doesn't. Then what? You only have 1 string which you can translate, not two. So as translator you are forced to use the shortened version which will be used for both of them. Not to mention the thing I said above about how translations can be different for the same English version depending in what context and what dialog they are used on.
So, this is totally different than:
You have 1 dialog window like this:
---------------------------------
What do you want todo?
[X] Go to &bed
[ ] Go to &toilet
[x] Give me a &pillow
or: [x] Give me a &radio
[&OK] [&CANCEL]
---------------------------------
When you select "bed" the seconday option "pillow" is shown and "radio" is not shown.
When you select "toilet" the secondary option "radio" is shown and "pillow" is not shown.
Now, "pillow" and "radio" can have the same ampersand as these options are not shown and used simultaniously (remember the chat logging panel in the Plus! preferences, its almost alike). Thus todo what you suggest, to make everything in topics as it is seen in real so one could easly check ampersand collisions, a translation file should look like this:
[Window.whattodo_1]
bed=Go to &bed
toilet=Go to &toilet
pillow=Give me a &pillow
OK=&OK
Cancel=&Cancel
[Window.whattodo_2]
bed=Go to &bed
toilet=Go to &toilet
radio=Give me a &radio
OK=&OK
Cancel=&Cancel
As you can see, many duplicated topics and keys will be nessecairy with this. Imagine that this isn't just 1 dialog we're talking about but hundreds of dialogs with quite often many many suboptions, subsuboptions, subsubsuboptions, etc.... just like Plus! and you would have an idea of the big mess and total uselessness it will create.
This is simply not doable, not now, not from the start of creating Plus!, never...
A decent translation file for the above must be like:
[Window.whattodo]
bed=Go to &bed
toilet=Go to &toilet
pillow=Give me a &pillow
radio=Give me a &radio
OK=&OK
Cancel=&Cancel
And it is up to the translator (and the AC-program) to know that "pillow" and "radio" can have the same ampersands.
For the AC-program, an index file must be made like this:
(to put it simply):
bed=toilet, pillow, radio, OK, Cancel
toilet=bed, pillow, radio, OK, Cancel
pillow=bed, toilet, OK, Cancel
radio=bed, toilet, OK, Cancel
OK=bed, toilet, pillow, radio, Cancel
Cancel=bed, toilet, pillow, radio, OK
each key which is read out contains a list of the other keys which needs to be checked against. Notice the lack of "pillow" in the "radio" key and vice versa. This makes that the program 'knowns' that "radio" and "pillow" can have the same ampersand as they are not checked against each other.
quote:
Originally posted by Kian
And again: I am just thinking about it - messing around with the thoughts - but I know that Patchou has his reasons to do things the way he does... and I accept that... I am just thinking of how it could be done elsethen...
I know
but the point is it can NOT be done otherwise in a decent way....
--------------------
EDIT: @Kian: rofl at your reply... I know the feeling
thank god that webcams don't automatically send pictures
@ZrednaZ: lol... well, you're actually right...
need to cut down on lengthy posts
/ 
