I didn't change anything, and it's not directly related to Odyssey itself, it's the default behaviour of MUI string class when pressing home/end/pgup/pgdn keys. Maybe default shortcuts changed on MUI OS4? Anyway, these events can still be caught to do something else, it's quite trivial to do.
As for "Paste to URL" contextmenu item, it was never enabled in the MorphOS build, AFAIR.
Err, while it might happen in URL address if you didn't remap mui shortcuts for string class, it definitely shouldn't happen in webview text fields. Pgup/down/home/end are handled entirely differently inside the webview, and this can't happen (on MorphOS at least).
I didn't change anything, and it's not directly related to Odyssey itself, it's the default behaviour of MUI string class when pressing home/end/pgup/pgdn keys. Maybe default shortcuts changed on MUI OS4? Anyway, these events can still be caught to do something else, it's quite trivial to do.
I don't know if that default shortcuts were changed in our MUI4, but even now that shortcuts still working fine under OWB 1.9 (with both MUI 3.9 and 4.0) but give us garbage starting from OWB 1.16
Sadly I can't verify the combo "OWB 1.16 + MUI 3.9" because our latest OWB works only under MUI4
However maybe that shortcuts were "embedded" before (in OWB 1.9) and so worked while now they are handled directly by MUI4 and need to be configured ?
Exactly what are the default behaviour under MUI4/OWB on MorphOS when you press that shortcuts into your address bar area ?
Quote:
As for "Paste to URL" contextmenu item, it was never enabled in the MorphOS build, AFAIR.
Ok so to understand at 100% ... if (on MOS) you press RMB over the address bar of OWB you will got only that options ?
You could be right about it not being directly an Odyssey bug, but a newly introduced MUI4 one. If my imagination is not playing tricks on me I saw it happen elsewhere.
I didn't change anything, and it's not directly related to Odyssey itself, it's the default behaviour of MUI string class when pressing home/end/pgup/pgdn keys. Maybe default shortcuts changed on MUI OS4?
Its just in 1.9 i use betterstring/hotkeystring/textinput/textinputscroll 3d party classes, as at those times our mui didn't have that functionality of mui4. Once it was implemented i switch to it, to make it the same as on mos and so it reacts now the same as on mos.
Quote:
As for "Paste to URL" contextmenu item, it was never enabled in the MorphOS build, AFAIR.
Can be again same about 3d party classes.
@samo Quote:
I don't know if that default shortcuts were changed in our MUI4, but even now that shortcuts still working fine under OWB 1.9 (with both MUI 3.9 and 4.0) but give us garbage starting from OWB 1.16
Because i use in 1.9 BetterString class as at those times String class was sucky enough, and later i swith to be same as on mos.
Quote:
Ok so to understand at 100% ... if (on MOS) you press RMB over the address bar of OWB you will got only that options ?
- Cut - Copy - Paste
It's like that ?
You don't belive my reply in tickets ? Of course i check it before i write reply to issue, and while i not Fab, yes, its like this on morphos (rechecked again).
Quote:
Exactly what are the default behaviour under MUI4/OWB on MorphOS when you press that shortcuts into your address bar area ?
The same as on os4 as i told before, and Fab already explain in previous post: its default behaviour of mui4 to draw those codes (if you didn't reassign them in muiprefs/keyboard).
Quote:
44~45~
Btw, you can go to _any_ string in any mui app, and press ctrl+home to check that it the same everywhere (even in muiprefs/string , where "example" words placed: make it active and press ctrl+home)
@djrikky Quote:
This bug is also present in text fields as well kas1e.
In all mui4 text fields: yes, but its not bug, its how it done currently on both mui4 on mos and on aos. Its just show you that by default those combos didn't configured to anything, and you have raw codes, but you can configuer it in mui itself as you wish (muiprefs/keyboard/)
Quote:
You could be right about it not being directly an Odyssey bug, but a newly introduced MUI4 one. If my imagination is not playing tricks on me I saw it happen elsewhere.
You wrong. There is no bug introduced, its how it reacts on morphos, as well as there is no those characters when you press ctrl+home or whatever in webkit's fields, only in mui4 ones.
Edited by kas1e on 2014/2/12 15:36:57 Edited by kas1e on 2014/2/12 15:42:32 Edited by kas1e on 2014/2/12 16:07:46 Edited by kas1e on 2014/2/12 16:23:41
You don't belive my reply in tickets ? Of course i check it before i write reply to issue, and while i not Fab, yes, its like this on morphos (rechecked again).
Naa it's not that of course, i believe you but it was just to be sure at 101% from another source ... aniway if i don't understand wrong and if all are related to MUI what do you think if we ask Thore to implement also a couple of new combos (in Keyboard section of MUI) to react in address areas as it was in your old betterstring/hotkeystring implementation ? ..
aniway if i don't understand wrong and if all are related to MUI what do you think if we ask Thore to implement also a couple of new combos (in Keyboard section of MUI) to react in address areas as it was in your old betterstring/hotkeystring implementation ? ..
I assume everthing can be possible alerady to configure it as you wish in mui4. But if not, then yep, can be good idea maybe to add to default string class some more things as it was in betterstring (in mui prefs Keyboard editing is one which we need to expand).
At least this one:
Quote:
SHIFT+Home/END --> For going to the start/end of a line in an url
Not need it , as you have it now just without shift (just home and just end). Check cursor/line_start and cursor/line_end in muiprefs/keyboard, you can change those ones or even add your ones (i.e. you can remap to as many combos as you wish, you can add there your shift+home/shift+end combos if you want them. I.e. in mui4 you can not only change current ones, but you can add new ones together with olds ones (press on that gadget) ).
As for
Quote:
CTRL+Home/END --> For selecting the entire url automatically
That one maybe worth of adding (checked already how it reacts on betterstring class, pretty handy indeed). Through is not selecting whole entire url automatically , but just select from cursor to left or to right all the text, pretty good indeed. Will make proper request for enhancemnt for mui now
Edited by kas1e on 2014/2/12 15:44:58 Edited by kas1e on 2014/2/12 15:45:28 Edited by kas1e on 2014/2/12 15:45:43 Edited by kas1e on 2014/2/12 16:09:42 Edited by kas1e on 2014/2/12 16:14:46
@samo I made enhacment req for adding "marking" in the mui4 string class (not visibly now as i wasn't loged in when write it, so will appears to be visibly a bit later),
i.e. 4, 2 for text editing :
Mark All to Left (and default Ctlr+End) Mark All to Right (and default Ctrl+Right)
And 2 for currsor
Mark Left (default amiga+left , as ctrl+left already taken by default for word jumping) Mark Rigth (also default amiga+right, because of same as previous).
All can be reconfigured of course as anyone wish, just to have some defaults.
Not need it, as you have it now just without shift (just home and just end).
Yes you right on this :)
Quote:
That one maybe worth of adding (checked already how it reacts on betterstring class, pretty handy indeed).
Sure, it will be pretty usefull to have it back!
Quote:
I made enhacment req for adding "marking" in the mui4 string class (not visibly now as i wasn't loged in when write it, so will appears to be visibly a bit later),
Thanks mate, question solved then
Now even if not related to our port, still only to see this latest thing related to the "Paste to URL" option, Fab says that it isn't enabled in MorphOS (i think he refer as a direct option in context menu) but it's for sure availible under the "Edit" menu and it works from there
This one would be pretty handy to have also into the contextmenu because it's not just a simple "pasting option" but is also able to paste an URL --> and then load automatically the page
However this option is not so friendly when accessible only by the edit menu, so having it also into the contextmenu would be perfect! (Firefox have a similar functionality)
Of course this is a direct feature request for Fab (next OWB), not for us
but it's for sure availible under the "Edit" menu and it works from there
I can't check now, but maybe it just was some additional setting to contextmenu done myself :) I mean, you can construct main context menu as you wish, and i assume put that functionality where you need by mime types.
I implemented this paste&go url contextmenu item, but it appeared in a submenu instead of below the other entries, and it didn't look good, that's why i disabled it, since i didn't find how to put it at the same level as the other entries. And i had much more interesting things to do in the browser in the meanwhile.
And by the way, if you find it's not friendly from edit menu, you can just press amiga+g, it's even faster that way.
I can't check now, but maybe it just was some additional setting to contextmenu done myself :) I mean, you can construct main context menu as you wish, and i assume put that functionality where you need by mime types.
I don't think it will work because it's not the same user configurable menu, that copy and paste functionalities (for the address area) seems internal so to change them i presume you should modify the current source code
@Fab
Understand, well no a big problem but i hope someday you will implement it at 100%, for now of course i'm using the amiga+g combo
@Samo Thore deal already with that enhancement and i already have beta in tests: now "alt" qualifier added to do marking. I.e. all previous combos works as before, just if you press them with alt, you mark data. If you press alt + cursor keys, it mark single characters, if you press alt+home or alt+end, it mark text from cursor position till end, or till begining of string, you also can mark by words : originaly with ctrl+cursor keys you can jump over words, now, the same combo but just with added alt (i.e. alt+ctrl+cursor keys) will mark words. I.e. just check current muiprefs/keyboard, and imagine that for almost everything you can add "alt" now, to make the same, but for marking. Also was added some more handling for input to avoid typing of those characters when they in no use. In other words, its cool now. Will be good if morphos devs will add to their mui something like this, can help for usability for sure.
Yes i'm following the daily progress from the MUIdev site so i read that already! Great news for sure, most of the problems related to the OWB usability are now solved and just the double buffering still in progress
It only mean that i use it everyday, but didn't releaze because there is that problem about which i told (and which present on all versions, and in 1.9 and in 1.16): some sites crashes on os4 version while the same sites but on morphos version didn't. And so, i think about how to make it all in one new topic, with links, different crashlogs, and so everyone can suggest what going on. I curently trying myself understand why it happens, and have only ideas that it can be because of timing as Joerg say me before (but i tried his timing code from his owb, and it didn't help, or i just use it wrong) , or, which is also possible, some thread runs outside of main process somewhere, or, for compiler i use there is some bug which make something bad, or .. or whatever else :)
So its kind of same problems, and i am sure it crashes for ppls offten on heavy pages because of exactly that. But webcore code the same of course and i change nothing in terms of JS for example or so. If only there is somewhere something which should be done somehow differently for os4, but what and where .. Maybe some different compilation flags.. I do not know currently. Maybe "fastmalloc" can be disabled, maybe something else. Dunno. Maybe there need to open somewhere new instances of ISocket, to avoid that problem (as seens from crashlog its related to handle of sockets). Or maybe all about timing. Really dunno. Maybe os4 catch something which morphos didn't and bug present just in webcore itself.
As both crashes point out on 0xCCCCCCC (as i on debug + munge), it mean "you have tried to free a Node a second time". So maybe some wrong free() somewhere, or dunno what. Together with DEADBEEF in one of registers its cleary point out on problems with memory, but it all can be anything.
@All Anyone skilled and brave enough to help with and dig in into code ?
Edited by kas1e on 2014/2/18 5:52:37 Edited by kas1e on 2014/2/18 5:53:20 Edited by kas1e on 2014/2/18 5:54:31 Edited by kas1e on 2014/2/18 6:05:21
@tlosm You can try it yourself on 1.16 (on bombermine.com for example). Both sites didn't allow you going futher than just main pages without JS: so i can't say if it JS related or not. And even if, it still didn't mean that its related to JS itself, as it can be just with enabled JS a lot of data handles, and bug come out.
Through as i see Kicko deal with all his problematic sites by disabling JS, but still it can be not JS itself, but anything else. And crashlogs point out on timing/sockets handling, not on something in JS.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
