AWS Thinkbox Discussion Forums

Linux - Monitor Bug (menus go offscreen)

Deprecated Deadline 6 Bug Reports
#1

When right clicking to get the contextual menu, sub menus that are big enough are going off the bottom of the screen (making it rather difficult to select those items!).

Details:
Linux x64 (Fedora)
Beta 2

Steps to reproduce: While a super user, right click on a slave to get the menu. Selecting ‘Remote Control’ causes that sub menu to flow past the bottom of the screen.

Cheers!
-Matt

#2

Yeah, this is a known issue, and unfortunately it’s a mono issue. We’ve tried to workaround it by keeping the menus shorter (which is why the job right-click menu has an Options sub menu), but as you’ve discovered we can’t workaround it completely.

Cheers,

  • Ryan
#3

Hey Matt,

We might look into writing our own menu code in hopes of workaround this issue, as it is an annoying problem on both Linux and OSX. Are there any other issues with the Monitor on Linux (or OSX, since you use both) that you would like to see fixed? I know there is the tooltip issue, but I would probably leave that at low priority for now.

We’ll compile a list, and see if we can pick them off during the Deadline 5.x cycle.

Thanks!

  • Ryan
#4

Off the top of my head, just some very minor things, but I highly suspect they are Mono things, not Deadline things:

  1. Window redraw/refresh is slow and dirty (especially noticeable on window resizing)
  2. Resize cursor shows up incorrectly and isn’t active. You have to go right to the edge to get the window manager’s resize cursor, and resize that way.
  3. UI’s and startup are more sluggish than on windows.
  4. Sometimes the focus following and/or window focus seems to be different than the native window manager.

I’ll keep an eye out and ask people here to let me know if they come across issues.

Cheers!
-Matt

#5

Thanks Matt!

Yeah, those are all Mono-related issues, but I’m starting to feel that’s not a good excuse anymore. :slight_smile:

Quirky stuff like off-screen menus and resize cursors can hopefully be fixed by overriding some default behavior (we already have a ton of “if Mono, do this, else do that” code), but things like redraw and UI speed might be out of our control.

For (3), do you find the overall use of the UI sluggish, or is it just a startup thing?

For (4), can you provide more details about what you mean?

Thanks!

  • Ryan
#6

Both the UI and startup seem slugish. As example, windows seem to come up slower than in, er, Windows, and scrolling definitely is slower and has a mess of redraw issues. Startup time is definitely slower than on Windows.

For difference in focus, an example is with the scroll wheel: scroll wheel events are sent to whatever window the mouse is over, regardless if it has focus in the native window manager, but Monitor doesn’t seem to receive them.

Maybe eventually moving toward Qt for the GUI could work better down the line? (Maybe for Deadline 6 or 7). That way, the interface would be unified more tightly over all platforms (and no more reliance on X11 for OSX). Also, for Deadline Launcher, you could use native system tray for Linux and OSX too, instead of having a ‘Launcher Window’ on non-windows platforms.

It looks like there’s .Net bindings for Qt as well: en.wikipedia.org/wiki/Qt_%28toolkit%29#Bindings

Cheers!
-Matt

#7

There are quite a few toolkits available that support Mono:
mono-project.com/Gui_Toolkits

Currently, WinForms is used for everything, which is why we depend on X11 on OSX. Eventually, we would like to have a native look on each OS. Maybe version 6 or 7…

Cheers,

  • Ryan
Privacy | Site terms | Cookie preferences