yumin9822 / transmission-remote-dotnet

Automatically exported from code.google.com/p/transmission-remote-dotnet
0 stars 0 forks source link

support for mono #13

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
are you interested in support for mono?
with a very little effort i have, actually transmission-remote-dotnet
running here under mono on Linux

Original issue reported on code.google.com by theli.ua on 23 Jan 2009 at 6:36

Attachments:

GoogleCodeExporter commented 8 years ago
I am interested in mono support. I've got it running before by just deleting 
pieces
of code (I didn't know about those #if statements), so thanks for this neater 
way of
doing things. I'll commit it soon.

Are you using authentication? Last time I got it to run it wouldn't 
authenticate.

Original comment by AlanF...@googlemail.com on 24 Jan 2009 at 7:01

GoogleCodeExporter commented 8 years ago
though it's a pity mono doesn't define something to recognize it at compile 
time...
that "MONO" i chose i defined myself in project file for mono.

I'm going to create a Makefile for building on Linux without Monodevelop 
(monodevelop
supports MS Visual Studio solution and project files) and submit it ... someday 
:D

yes, i'm using authentication and had no problems authenticating

Original comment by theli.ua on 25 Jan 2009 at 8:24

GoogleCodeExporter commented 8 years ago
Nice :) I think it must have started working again after the embedded http 
server was
changed around 1.40. I'll give it a try next time I'm on Ubuntu.

Original comment by AlanF...@googlemail.com on 25 Jan 2009 at 11:15

GoogleCodeExporter commented 8 years ago
Can you tell me what version of mono you are using? I'm using 1.9.1 which comes 
with
Linux Mint 6 (Ubuntu 8.10).

It seems to fill up the torrents list and then crash. It looks like a bug in 
mono
winforms rather than transmission-remote-dotnet. I've attached the crash report.

Original comment by AlanF...@googlemail.com on 29 Jan 2009 at 8:07

Attachments:

GoogleCodeExporter commented 8 years ago
i'm using 2.2 and as i remember winforms implementation improved greatly from 
1.9.x
branch

messages in your log also looks as a mono's winforms problems to me 

i can i'm using transmission-remote-dotnet on a daily basis and haven't 
experienced
any problems ( not counting a very bad look-n-feel of Winforms in Linux :) )

btw, i'm thinking of adding another (gtksharp) frontend to 
transmission-remote-dotnet
when i'll have a time (just an alternative MainWindow implementation)

Original comment by theli.ua on 30 Jan 2009 at 8:14

GoogleCodeExporter commented 8 years ago
Suppose I'll compile mono then. A gtksharp frontend would be really cool, and
something that I'd be interested in helping with. I've done a little with gtk 
sharp,
but I'm not really sure if it'd be straightforward or complex to hack away 
porting...

Original comment by AlanF...@googlemail.com on 30 Jan 2009 at 10:17

GoogleCodeExporter commented 8 years ago
I tried to run transmission-remote-dotnet on Mono on Mac OS X and I got:

** (Transmission Remote.exe:668): WARNING **: The class 
System.IO.Pipes.NamedPipeClientStream could not 
be loaded, used in System.Core, Version=3.5.0.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089

Unhandled Exception: System.TypeLoadException: A type load exception has 
occurred.
  at TransmissionRemoteDotnet.Program.Main (System.String[] args) [0x00000]

Any ideas on that one?

Runs great for me on Windows... absolutely love it - was hoping it would 
transfer over to Mac OS X without 
needing a virtual machine running

Original comment by scott.ta...@gmail.com on 7 Feb 2009 at 6:32

GoogleCodeExporter commented 8 years ago
scott, simple patch posted here won't make binary releases of 
transmission-remote
work on mono yet

if you wan't to try transmission-remote with mono you need to compile it 
yourself:
just make an svn checkout, open solution file with Visual Studio, Monodevelop or
SharpDevelop 
in project options add an additional define - "MONO"
build
that's it

Original comment by theli.ua on 7 Feb 2009 at 7:08

GoogleCodeExporter commented 8 years ago
I built and installed mono 2.2 hoping to find it would fix the problem I 
described,
but it didn't. I managed to track the problem down to the drawing of GListBox (a
custom class which provides images next to the various states like downloading,
seeding etc). Does this display without issue for you?

I've added some more #if's to use a simple ListBox for mono instead. Although 
this
didn't crash the application, it appears empty. I'm guessing it starts with an 
index
other than zero because the torrent list (all paused at the time) populates then
filters to nothing. I have to blind click at the top of the listbox for it to 
restore.

There seems to have been improvements to the appearance between 1.9 and 2.2, 
but the
main issue is it's very sluggish at times. While on windows the listviews will
populate very quickly, there's a notable delay between each item being added. I
thought using SuspendLayout()/ResumeLayout() would prevent this, but it doesn't.

Original comment by AlanF...@googlemail.com on 8 Feb 2009 at 7:25

GoogleCodeExporter commented 8 years ago
screenshot of remote.net running here on linux with mono
http://img5.imageshack.us/my.php?image=tnetcy2.png

not sure why you have all those troubles - i didn't have any 

though i think transmission-remote-dotnet really needs gtksharp UI ;)

Original comment by theli.ua on 8 Feb 2009 at 7:41

GoogleCodeExporter commented 8 years ago
I'm suprised how good it looks there. You've made me change my mind about 
explicitly
disabling stateListBox on mono.

It's probably my setup that's the problem. I'm downloading the mono vmware 
image and
will try that. If that works, I may release a mono binary sometime.

A couple of other 'issues' to record here so I remember them:

1) MainWindow needs a minor resize for the ToolStrip to show all the items.
2) Self signed SSL (so basically any SSL) certificates aren't accepted.

Agreed, a GTK# UI would be very nice. Unfortunately I don't have the time to
implement it. I don't think it would be straightforward to port the whole thing 
at
once, but it would probably be easier to get a working UI, then a lot of the 
classes
(all the commands,CommandFactory,Requests,Torrent,ProtocolConstants) are mostly 
reusable.

Original comment by AlanF...@googlemail.com on 8 Feb 2009 at 10:14

GoogleCodeExporter commented 8 years ago
1) this issue is present
2) can't test 

Original comment by theli.ua on 9 Feb 2009 at 6:46

GoogleCodeExporter commented 8 years ago
Have you both tried the new mono build? It's built in visual studio but seems 
to work
reasonably well in Mono and will let you use it as a .torrent handler.

I've put a list of most of the issues I've noticed on a wiki page.

Original comment by AlanF...@googlemail.com on 10 Feb 2009 at 8:14

GoogleCodeExporter commented 8 years ago
works for me

Original comment by theli.ua on 11 Feb 2009 at 6:19

GoogleCodeExporter commented 8 years ago
It certainly works now on Mac OS X under Mono (good work) but unfortunately 
it's not really usable

I would go into more detail but I'm guessing that you don't have an OS X 
machine to test it under

Original comment by scott.ta...@gmail.com on 12 Feb 2009 at 6:07

GoogleCodeExporter commented 8 years ago
I imagine the usability problems you're experiencing are the same I've noticed 
on
Linux. The main one being that the UI is sluggish, and a few others I put on 
the wiki
page for mono.

The problem seems to be with Mono's winforms implementation. As has been 
mentioned, a
GTK# UI would be nice. Since it was/is very little effort to get it "working" 
on mono
I'll keep making it capable of building under it, but it's still really 
unsupported
and Windows is the main focus for me. I use it on Ubuntu occasionally though, 
and I'd
say it's borderline usable but certainly is nowhere as good as the windows 
version.

Original comment by AlanF...@googlemail.com on 12 Feb 2009 at 7:46