-
-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: New element attribute "diagram" #687
Comments
I'd like to contribute (to) this feature by (helping) to implement it. Current work-in-progress resp. demonstrator is to find at forked-repo/branch
|
Hi We will discuss the idea, but I see some potential problems with it:
Maybe there is an alternative way of doing things which already works for your usecase?
So my first impression is that I'm not sure if there is enough benefit to such a feature to break the assumption that Umlet only writes to the filesystem if explicitly selected by the user using the filechooser. |
@afdia Thx for your precious feedback. The following I have to say about each point (I gave them ids PotProb_(i) for the potential problems and PotAlt_(j) for the potential alternatives in order to ease communication on it). PotProb_01In the current sketch of realization I see two situations of "already exist": a) At least one of the output files to get exported already exist(s). Regarding a): Page(s) are never exported without exporting the entire file. So in the situation when a user exports, via the GUI, the file and she/he has exported previously then the file of the export of the entire file also exists and Umlet asks the user if she/he wants to overwrite or not. Exception: The situation that file(s) exist(s) containing page exports but there is no file of the entire content is possible. Then the user wouldn't be asked. I rate this situation not very likely and would live with the fact that page exports would be overwritten without prompt before. We could let Umlet show an info/warning about that afterwords in GUI and also console in order not to overwrite anything silently. We also could let Umlet block the export in this situation, tell it to the user and tell him how to handle this situation: By deleting the page export files as well. Regarding b): Overwrite a page export with another page export of the same umlet-file when exporting: This is not possible by design because Design_b) (see issue description). PotProb_02By design Umlet never exports the pages without exporting the entire content. I think this would handle this situation appropriately. PotProb_03I don't see any problem here because ... a) basename-stem of file: The facts written in answer of PotProb_02. PosProb_04Currently I don't have (enough) experience with neither Umletino nor the VS Code plugin to say about this. I'll dive into it. PosProb_05Because the filenames of the page exports are always the filename of the export of the entire content with a suffix to its basename (suffix = pagename) I don't see any problem here. PosProb_06See my answer to PosProb_05. |
PotAlt_01This tedious and time consuming process I'd like to automize with this new feature. It is no alternative to the feature. PosAlt_02This is an improvement to PotAlt_01 but still no alternative. PosAlt_03This is exactly what I'm doing currently. Our Umlet sketches are organized like this as soon as we enter the phase that we use them in documents. In previous phase(s) we have the entire content in one file and benefit from the advantages of the open canvas. The problem is that we lose those advantages as soon we enter the documentation phase. So I don't rate this as an alternative to the suggested feature. |
I have thought about it and I'm still not a fan of such a specific feature, but what about a more generic alternative to it?
Then you set up e.g. 4 batch export scripts each targetting another line which is only present in the desired collection of elements you want to export. This has several advantages:
|
@afdia Thx again for following up with my idea about the new feature so deeply. I understand your doubt about it because it ...
I'd like to baptize the latter possible alternative with the new batchmode parameter as PosAlt_04 and derive a PosAlt_05 from it as follows: PosAlt_05derived from PosAlt_04 a) Umlet gets enhanced by a new attribute for graphical elements with name a.1) It is a replacement for the attribute a.3) a.4) Maybe it could be restricted that attribute a.5) Umlet maintains a list of graphical elements bearing the attribute b) The attribute c) Graphical elements bearing the attribute Details of c.1): Details of c.2): (Alternative could be that they appear as soon the first graphical element bearing attribute c.2.3) When one of the buttons is pressed, Umlet zooms the diagram so that the target element is being displayed entirely with maximal possible size in the view-pane. End of PosAlt_05. Best regards! |
Replaced content of description. Before, the description contained the very first suggestion which was: Usecase: As an Umlet user I want to be able to define one or more named page frames within an Umlet file. Connected to that the export command (to any format, including uxf) exports an output file for each page frame along with the file containing export of the entire content. The element which defines the page frame and all the elements which are completely inside its rectangular circumference are exported per page. Business value/benefit: This is so that I can include exported pages frames as figures in documents (such as reST with Sphinx) while keeping the benefits of having Umlet content in the endless canvas. Additional details:
Design_b) Umlet shall take care about that the user cannot create a |
Sorry for the delayed reply. The concept of a specialized batchexport option would avoid those problems and keep the UI simple while still allowing partial export of a diagram. Besides the mentioned -containsline="//exportPage1" approach which exports only elements which contains the given line within its properties (as suggested above), it could also be implemented similar to the new diagram attribute but hidden for normal users: A new batchargument e.g. -container=//uniqueLine which instructs umlet to only export elements which are within the space of the given container element. Instead of a new diagram attribute to define containers, I would simply search for the element which contains the specified line (here //uniqueLine, but can be anything. maybe throw an exception if no unique non-relation element can be found). When the element is found, Umlet only exports elements which are fully overlapping the specififed element. The batchexport could be called multiple times with different containers, therefore the outputfilename of each container would be contained within the batch-call and not partially distributed into element properties (which I see as an advantage because I don't like the idea of diagram elements having influence on filenames which may cause problems with different OS like Windows vs Linux allowed characters in filename or even security issues when we forget to forbid all ways to traverse directories e.g. diagram=../../../name) |
I'd like to propose following new feature based on Umlet 15.0.0:
see Possible-solution-Alternative PosAlt_05 in post #687 (comment) below
The text was updated successfully, but these errors were encountered: