aMule Forum
English => en_Bugs => Topic started by: stsp on June 25, 2005, 01:18:03 PM
-
Hi.
The friend of mine uses aMule and it doesn't seem to work
right for him. Here is the screen-shot:
He is annoyed by this "bottom-line" that eats up the half of the
screen. The wx version is 2.6.0.
On my PC there is no such problem, so it looks like a bug to me.
Any ideas how to get the proper layout?
-
thats due to the fact the button-bar resizies with the msg at the left side...so you can actually read it ;)
btw I remove the picuture because there is some p**n things on it, and we dont want this here..
-
> thats due to the fact the button-bar resizies with the msg at the left side...so you can actually
> read it
OK, well, so how to disable it or do something? This is really
weird and he claims it covers the window where you add a
new URL, so it is difficult to add the downloads. And now I
see also some buttons and info strings are half covered.
This isn't good.
> btw I remove the picuture because there is some p**n things on it, and we dont want this
> here..
Oh, you probably mean those stupid file names he downloads...
I haven't noticed that, sorry.
-
well the size of the bar will change with the length of the msg,
so in his picture he had a faily long msg, thats why the bar was sooo big, when he has a smaler msg, the bar will be smaker. but actually there is no option to prevent it from resizing.
what you could do is for example reconnect to a server. since this msg is much smaller then the acutal one he has atm.
another thing would be increase teh screen size from 800x600 to 1024x786...or whatever it was.
then there is more space and so it should not be so bad anymore
-
> so in his picture he had a faily long msg, thats why the bar was sooo big, when he has a
> smaler msg, the bar will be smaker. but actually there is no option to prevent it from resizing.
I understand. IMHO it makes sense to limit the resizing so that it can happen,
but not up to the level where it starts to cover the usefull things.
And as for the option - disabling resizing is too miserable for a new option,
but how about the option for disabling that messages entirely?
> what you could do is for example reconnect to a server.
Thanks, lets see if it helps, but some more fundamental solution would be
much welcome :) I can't help feeling that aMule itself is guilty here too.
-
well amule is only guilty showing you the full msg, instead of cutting it off after say 10chars...but most often you want to read teh actuall msg, and not just a little piece of it
-
By the way, this behavior depends on the window toolkit that wx is using. This doesn't happen with wxMac, and I know it doesn't happen for all GTK users, either.
-
its gtk2 feature...
-
stefanero:
> well amule is only guilty showing you the full msg, instead of cutting it off after say 10chars...
In my eyes it is guilty by allowing something to grow
arbitrary, covering the other elements.
> but most often you want to read teh actuall msg, and not just a little piece of it
In that particular case I'd prefer to have an option
for disabling it entirely, but still the controls must
never screw up each other, IMHO.
ken:
> By the way, this behavior depends on the window toolkit that wx is using.
> This doesn't happen with wxMac, and I know it doesn't happen for all GTK users, either.
How exactly they behave in that situation? Maybe I should try wxUniversal
then?
-
it has nothing todo with wxUniversal or anything...
just recompile wxGTK with
--with-gtk1
and then the msg will not resize the status bar anymore,
there is no option to disable the resizing
and I dont think its worth implementing it, since I doubt to many people run amule with 800x600 ;)
-
> it has nothing todo with wxUniversal or anything...
Why? I don't understand. It works on wxMac, works on
wxGTK on GTK+, yet have nothing to do with wxUniversal?
> just recompile wxGTK with
> --with-gtk1
Duh... I don't like asking before trying, but since compiling
wx takes so long... Do you think it will really work? I mean,
GTK+ doesn't seem to have the unicode support, while
GTK2 does, and so how good the local chars will work?
And I really think there are no more the GTK+ libs in the
modern distros.
So I think wxUniversal is more practical, unless I am
missing something here.
> there is no option to disable the resizing
No, not resizing! To disable that message window
completely! Of course an option to disable resizing is
something miserable, but an option to disable some
sub-window looks better.
And still, can you please answer this question: the
fact that the controls gets overlapped, is it a bug of amule,
of wx, of GTK2, or not a bug at all but a feature? I seem to
still can't get this one right:)
-
that it gets overlapped is due to the fact that gtk2 tryes to make the windows fill out the full size, so while on gtk1 they ahve fixed sizes on gtk2 the windows are somewhat "floating" and rezize depending on the msg.
thats teh same for the controls and msg window.
it works on mac because mac uses a completly different window toolkid under wx, linux uses gtk1 or gtk2 and they behave differnet for rezizing, and it looks that the mac gui toolkit behaves in that situation like gtk1 does.
so compiling wxGTK with gtk1 would help the resizing issue, but would of course make all russian chars not readable since they are unicoded.
stefanero
-
It's wx fault for me. you specify a fixed size, yet it resizes.
-
You could also try wxMotif, but I don't know whether it accepts unicode or not.
-
Originally posted by stsp
ken:
> By the way, this behavior depends on the window toolkit that wx is using.
> This doesn't happen with wxMac, and I know it doesn't happen for all GTK users, either.
How exactly they behave in that situation? Maybe I should try wxUniversal
then?
On the Mac, this control is one line in height, always. Longer messages are just truncated.
-
Originally posted by GonoszTopi
You could also try wxMotif, but I don't know whether it accepts unicode or not.
we actually dont compile with that, and it also does not support unicode I tryed 2days ago...
-
OK, thanks for the replies.
It definitely looks like a bug in wx and I've found several work-arounds.
They are attached. I can't justify the changes. It certainly looks like
some black magic happens when the size change is propagated
from the inner window to the sizer, rather than from the outer, and
the proportion flags look like have a reverse meaning in that case.
And why the wxST_NO_AUTORESIZE doesn't work I don't know too,
yet now the aMule seem allright.
If someone knowledgeable to wx can comment on that changes
of mine, that would be excellent, but in all my life I got used to the
fact that wx is somewhat very buggy (but now maybe it is just wxGTK).
-
And now the similair work-around.
-
both work?
-
> both work?
For me - yes. They do basically the same (wrong) thing, but they work.
I won't be surprised if they do some harm on another wx-target platform
though - I only have the wxGTK/GTK2 handy for testings.