 |
From: Julien Finet [mailto:julien.finet@kitware.com] I agree with you Andras, the layouts should be identified with a unique string. Feel free to enter a feature request (and suggest a patch :-) ) |
|
|
-----Original Message----- FWIW I've been playing with a module that does dynamic layouts [1] based on what data is loaded. Right now it just has a logic class [2] that I used from other code but I hope to give it a convenient GUI at some point. Anyway I ran into the same kind of issues with the layout ID so I ended up using 100 (since I'm redefining it all the time, I didn't see any reason for it to be a unique number). But one downside is that when you exit the application with a non-standard view number assigned and then restart the app you get a blank screen because an unknown layout id is saved in the settings. I see two options 1) if the layout id in the settings is undefined we could go back to the Conventional layout 2) we could add the layout xml to the settings and restore the last layout. I think 0000001 is better - any thoughts? -Steve |
|
|
From: slicer-devel-bounces@bwh.harvard.edu [mailto:slicer-devel-bounces@bwh.harvard.edu] On Behalf Of Julien Finet I agree with 1), vtkMRMLLayoutNode should be a bit more robust (default to DefaultLayout instead of NoneLayout). Julien. |
|
|
-----Original Message----- 1) is a simple solution, but not saving the selected layout in certain cases would be a strong limitation. We often define complete experimental setups by setting up everything in the scene then saving it. Implementing 1) would mean that we can never use custom layouts for these projects. 2) could be useful, because even if the module that defined the custom layout is not available on the Slicer instance where the scene is loaded (e.g., the corresponding extension is not installed), we could still see the correct layout. In addition to 2) there is still needed a policy to assign reserved layout enums or switch to string IDs (to avoid undefined behavior caused by multiple modules randomly redefining the same layout). Andras |
 |
On Thu, Feb 28, 2013 at 5:49 PM, Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com> wrote: We should really really reference layout by string. If we don't do it now, we will be scratching our head when we will actually implement it and we will have to tweak the scene reader so that older scene can be read. Patch are welcome :) 1) If not doing so, we could reference additional layout with the following scheme .. but doing so would be like promoting what we should NOT be doing. Layout Id would be computed using the following scheme: SlicerLayoutUserView We would then create a page on the wiki where we keep track of the moduleId. The wiki page would list all the ModuleIds: Foo: 0 The offset could be set to 100. 2) We could also use a hash function to go from string to integer. Hth |
 |
r22142 [1] helps with this. I've been using custom layouts and when I restart I was getting a blank screen. With this patch I think the situation is usable and probably no further changes are needed for my use case. [1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22142 |
|
|
Based on Steve comment, resolving the issue. While not "optimal", it is currently possible to create custom layour from either cpp or python. |
|
|
I agree that the current behavior is acceptable but it should be fixed at some point. I think it's better to keep track of this issue so that when someone touches the layout implementation then this problem can be be addressed as well. |
- Anonymous
