SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: shadm on May 07, 2015, 05:31:45 pm

Title: Window behavior v19.0.2.5 on Ubuntu 64bit
Post by: shadm on May 07, 2015, 05:31:45 pm
I run a dual screen XUbuntu 14.04 machine and I am finding some behaviors of the application that are constantly getting in my way.

I build the Linux kernel using Yocto several times per day, and often have to "refresh" the files by removing the source directory and re-copying it, which takes anywhere from 1-10 seconds.  When I return to SE, it will often ask if I want reload files.  Sometimes I like to see if any of the files I was working on actually changed so I select the compare all selected option.  In some cases, there are several files to go through and many have not actually changed.  SE throws up a dialog in those cases asking if I still want to diff them.  What I can't figure out is how SE decides where to put the dialog.  I feel like I'm playing whack-a-mole chasing each new instance from screen to screen until I've gone through all the files.

The other issue I deal with a lot, is the "resetting" my open dialog options.  It's even more confusing when I have opened files in another window.  Every time I open a different project or open SE, my open dialog is docked.  I have unchecked the "dockable" option, but that is apparently of no concern, it's docked anyway.  So, I select floating, and then go to uncheck dockable, but it is already unchecked.  Then I go about my business, the next time I Ctrl-<O> to open a file...docked in the other window.  So, I select floating again.  I go to uncheck dockable's already unchecked again.  Everything is fine again.  Open a different project or restart SE?  Go back to the beginning.  I attached a screen shot of the unchecked dockable option in my second window to show even before I undock, it is not dockable.

My last nitpick is the code windows themselves.  Maybe this is not supported, but it would be nice if I have my windows split in a certain way, they would be split the next time I open the project they were split in.  I don't notice this one quite as much, so I don't recall if it is both when I open a project or just when I launch SE.  At a minimum, a fresh launch means that all window splits are gone from all projects and they will have to be split again.

If I'm just shooting myself in the foot because I don't have something configured right please point me in the right direction to fix it.


SlickEdit Pro 2014 (v19.0.2.5 64-bit)

Serial number: XX000000
Licensed number of users: Single user
License file: /opt/slickedit/bin/slickedit.lic

Build Date: April 10, 2015
Emulation: Visual Studio

OS: Linux
OS Version: Ubuntu 14.04.2 LTS
Kernel Level: 3.13.0-51-generic
Build Version: #84-Ubuntu SMP Wed Apr 15 12:08:34 UTC 2015
Processor Architecture: x86_64

X Server Vendor: The X.Org Foundation
Memory: 90% Load, 8844MB/9782MB Virtual
Shell Information: /opt/slickedit/bin/secsh -i
Screen Size: 1920 x 1200, 1920 x 1200

Project Type: Cpp
Language: .bbappend (Bourne Shell)
Encoding: Automatic

Installation Directory: /opt/slickedit/
Configuration Directory: /home/user/.slickedit/19.0.2/
Spill File: /tmp/$slk.user.4196

Title: Re: Window behavior v19.0.2.5 on Ubuntu 64bit
Post by: Rodney on May 07, 2015, 06:52:44 pm
RE: Open tool-window not remembering floating pos when switching workspaces.
I can tell you why the issue with the Open tool-window is happening, but I don't have a hotfix unfortunately. SE maintains placeholders for the last docked, and last floating positions. Each placeholder has a timestamp, and the last/latest timestamp wins, but (obviously) something breaks down when restoring placeholders across workspaces. This one is definitely on our list to fix.

RE: Split editor window layout lost switching workspaces.
I've seen this before, but only when switching workspaces by executing vs.exe with a workspace (.vpw) as an argument on its command line. I do not see the problem when switching workspaces from the menu history (Project>[workspace history at bottom]).